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PREFACE 



The purpose of this manual is to help you become familiar 
with the Multics extended electronic mail system. This manual 
provides you with an illustrated discussion of the print__mail and 
read_mail commands for receiving mail, the send__mail command for 
creating and sending mail, and a large variety of useful requests 
and control arguments to aid you in utilizing the full capacity 
of the extended mail system. 

Readers are expected to know the Multics concepts and terms 
described in the 2-volume set, New User s ' I ntroduct ion to Multics 
(Order Nos. CH24 and CH25). These two manuals are referred to 
throughout this manual as the New Users' Intro - Part I and Part 
II. Also very useful is the Qedx Text Editor Users ' Guide (Order 
No. CG40) which is referred to as the Qedx Users' Guide. 

Section 1 of this manual introduces the Multics extended mail 
system. 

Section 2 reviews the print_mail command. 

Sections 3 and 4 introduce the send_mail and read_mail 
commands respectively, detailing the requests and control 
arguments most useful for novice users. 

In Section 5 you learn how to send messages to more than one 
person, how this affects message headers, and how to make further 
adjustments yourself to the header information. 



The information and specifications in this document are subject to change without notice. This 
document contains information about Honeywell products or services that may not be available 
outside the United States. Consult your Honeywell Marketing Representative. 



File No.: 1L13, 1U13, 1L53, 1U53 CH23-01 



© Honeywell Information Systems Inc., 1982 



Section 6 demonstrates several requests that the mail system 

Section 7 suggests a variety of techniques for advanced use 
of the mail system. 

The reference descriptions for the three mail system commands 
discussed in this manual are found in Appendix A. Mailbox 
commands are described in Appendix B. 

A glossary of the terms introduced in this manual is in 
Appendix C. 



Manual Conventions 

A few conventions and special symbols should be recalled 
before you begin to explore the Multics mail system. 

Throughout the manual, the term "mail system" is used to 
indicate the "extended electronic mail system". 

Terms within angle brackets (<...>) are used to convey the 
kind of word that you are to provide in the indicated space. For 
example, <User_id> means that you are to type a User_id. Any 
exceptions to this usage are noted. 

Technical or other unfamiliar terms are CAPITALIZED when used 
for the first time, and are included in the glossary (Appendix 
E). 

In examples, an exclamation point is used to indicate a line 
that you type at the terminal. You do not type the exclamation 
point, nor does Multics type it as a way of prompting you. It is 
strictly a typographical convention, to distinguish between 
typing done by you and typing done by Multics. 

All commands, and most requests and control arguments, have 
short names. The short names are used in most examples 
throughout the manual. 
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Mail system messages are referred to as both "messages" and 
"mail" in this manual. However, you will also encounter other 
types of messages as you work on Multics. "Interactive messages" 
are created by users with the send_message command. Messages 
from the Multics operating system are generally called "system 
notices". "Error messages" are also sent by the operating 
system, although these messages often begin with the name of the 
particular command that has been used incorrectly. Here are 
examples of all three of these types of messages: 

interactive 

message ==> From Lotte.ProjDog 08/01/80 09:03 mst Fri: Hi 
system 

notice ==> Mail delivered to Mnemosyne .Pro jCat . 
error 

message ==> send__mail: No project name supplied. FNewton 

Significant Changes in CH23-01 

Information on abbrev processing within the mail system has 
been added to Section 7. 



The first two appendixes of the original manual contained 
information on interactive messages and the memo command. These 
have been removed from the current revision. See the Commands 
manual for descriptions of these topics. 

Appendix A, which contains information on the mail system 
commands, has been extensively revised and has no change bars. 
It contains many new requests and control arguments. 

For purposes of clarity and ease of use, the MPM set has 
been reorganized. The six former MPM manuals, the Tools manual, 
and the RCP Users' Guide have been consolidated into a new set of 
three manuals. 

Multics Programmer's Reference Manual (AG91) 

contains all the reference material from the former 
eight manuals. It is referred to in text as the 
Programmer's Reference manual. 

Multics Commands and Active Functions (AG92) 

contains all the commands and active functions from the 
former eight manuals. It is referred to in text as the 
Commands manual. 
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I Multics Subroutines and Input/Output Modules (AG93) 
I contains all the subroutines and I/C modules froin the 

I former eight manuals. It is referred to in text as the 

Subroutines manual. 



The following manuals are obsolete: 



Name Order No . 

MPM Peripheral Input/Output AX49 

MPM Subsystem Writers' Guide AK92 

Programming Tools AZ03 

MPM Communications I/O CC92 

Resource Control Users 'Guide CT38 
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SECTION 1 



INTRODUCTION 



The Multics extended mail system allows you to receive, send, 
edit, and save messages in a variety of ways, using a set of 
three interactive (prompting) commands. The send_mail command 
enables you to send mail to as many recipients as you want, with 
the option of changing the elements of the message, such as who 
the message is to and from, what the title is, and the text of 
the message. A choice of two commands, read_mail or print_mail, 
lets you manipulate your incoming messages with either a complete 
and versatile mail processing system or a simple subset of this 
system, respectively. 

The read_mail and send_mail commands are complementary; 
although their primary tasks are different, they share several 
functions. For example, each command has access to a group of 
internal mail system info segments explaining read__mail and 
send_mail requests. The two commands also have many similar 
requests and control arguments. This can seem rather confusing 
at first, but as you read on in this manual and become more 
familiar with the mail system, you will see that two identical 
requests are usually part of a feature that is shared by the two 
commands, and therefore the requests both perform the same 
action. The manual is organized around the major features of the 
mail system and their related requests, in order to clarify these 
relationships ^ 
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THE MAILBOX 



You must have a mailbox to be able to receive messages. The 
mail system automatically creates a permanent mailbox for you, 
the first time you issue either the print_mail or the read__mail 
command. (This mailbox can also be created by issuing the 
accept__messages or pr in t__mes sages commands, because the same 
mailbox also stores incoming interactive messages.) The pathname 
for this default mailbox is: 

>udd>Pro ject_id>Person_id>Person_id.mbx 
as, for example, in this pathname: 

>udd>ProjCat>Willow>Willow.mbx 

for the user Willow registered on the ProjCat project. 

Your mailbox is a container for messages, with its own set of 
extended access modes. Extended access modes provide a 
specialized form of control, specifying what one can do with 
individual messages in a mailbox. Full access is granted to you; 
the default access for other users gives them permission to send 
messages to your mailbox, and to read and delete only their own 
messages. You may extend or curtail the access using mailbox ACL 
commands. Extended access modes and mailbox commands are 
described in Appendix B. 



Users With Multiple Projects 

Some users are registered on more than one project, and could 
thus have more than one personal mailbox. In this case it is 
important to create a mailbox in only one of your home 
directories, and to then make "links" from each other home 
directory to this mailbox, so that when you are logged in on one 
project and receive mail at another project, you can get 
immediate notice of the message and process it without having to 
log into the other project. 

As an example, user Ching is registered on three projects: 
ProjCat, Doc, and SoftWork. To make links to one of her 
directories (ProjCat) from the other two, she creates a mailbox 
in her ProjCat directory, with the pathname: 

>udd>Pro jCat>Ching>Ching.mbx 

After she has created one mailbox, she logs out and logs into 
another of her projects (Doc). There she types the link command, 
followed by the pathname of the mailbox from her first home 
directory: 

I link >udd>Pro jCat>Ching>Ching ,mbx 
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She logs out again, and repeats this from within her third 
project : 



I login Ching SoftWork 



r 10:37 1.485 32 
! link >udd>ProjCat>Ching>Ching.mbx 
L 

If she had already created a mailbox in her SoftWork project, the 
link command would ask her: 



j link: Do you wish to delete the old mailbox j 
I >udd>Sof tWork>Ching>Ching.mbx ? | 

J L 

She would answer yes to this question, because she wants only one 
mailbox . 



THE MESSAGE 

Messages all have a common format within the mail system. 
Each one begins with a header consisting of information about the 
message. The standard header tells you who wrote the message and 
to whom it was sent, the date and time the message was sent, and 
what the subject of the message is. This information is 
displayed in header fields, one field to a line. Here is an 
example of a standard header: 



Date: 1 August 1980 09:14 mst 
From: Moch.ProjCat 
Subject: picnic 
To: Willow. ProjCat 



The first line, the Date field, informs you of the date and time 
the message was actually written. The person who wrote the 
message is noted in the From field, and the title of the message 
is in the Subject field. The To field lists the person or people 
who received the message. 
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The text of the message follows the header, with one blank 
line between. Here is an example of a complete message: 



Date: 1 August 1980 09:14 mst 
From: Moch.ProjCat 
Subject: picnic 
To: Willow. Pro jCat 

There will be a meeting at 9:30 on Tuesday to discuss 
plans for the umpteenth annual office picnic. 
Everyone is asked to attend — please inform 
the others in your project. 



As incoming mail, the entire message can be read, kept, or 
deleted using the print__mail command. Within the read__mail 
command you can also answer the message, save it in one (or more) 
of several kinds of segments, and forward copies to other users. 
As outgoing mail, after you create the message with the send_mail 
command you can edit both the text and the header information, 
save a copy for yourself, send it to one or many people, and 
receive an automatic acknowledgement as soon as those users read 
it . 



REQUESTS ( read mail AND send mail ) 

All of the read_mail and send_mail options are available by 
issuing requests in the command's request loop, a part of the 
mail system that reads the request you type, performs the 
specified operation, and finishes with a prompt to you for 
another request. 

Request usage is governed by regular command language rules; 
therefore, you construct request lines just the way you construct 
command lines. For example, you can use semicolons to separate 
multiple requests on one line: 

send_mail: ! print ; send;quit 

and parentheses can be used for iteration (repetition): 

read__mail: ! (print delete) 1 

Refer to The New Users' Intro for a review of the Multics command 
language • 
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Control Arguments and Requests 



Control arguments and requests in the mail system can 
occasionally become bewildering. The read_mail and the send_mail 
commands together have over 60 control arguments. Mail system 
requests often have the same names as control arguments. In 
addition, many requests have their own control arguments, some of 
which are identical to command control arguments! It is 
important to employ these terms at their correct level (command 
level or request level). 

As noted in The New Users' Intro - Part I, a command typed to 
Multics, possibly including one or more control arguments, 
constitutes a command line: 



! rdm -log -list 

A request plus any of its arguments, called a request line, is 
typed after a mail system prompt: 

read_mail: ! list OR send__mail: ! log 

Be careful not to type a request on a command line: 



j ! rdm print 

1 read__mail: Entry not found. >udd>Pro jCat>Willow>pr int .mbx 

r 09:36 0.231 53 



or a command control argument as a request line: 



j read_mail: ! -list 

I read__mail: Unknown request "-list". Type "?" for 
j a request list. 

I 



Control arguments for both command lines and request lines are 
discussed in this manual. For the sake of clarity, most 
references to control arguments explicitly indicate "command 
control argument" or "request control argument", in order to 
differentiate between the two levels. In examples, command lines 
always begin with the command's short name (rdm), and request 
lines with the prompt ( read_mail : ) . 
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HOW TO USE YOUR MAILBOX 

A few pointers will help you to use your mailbox and the mail 
system successfully and effectively. 

Keep your personal mailbox empty, either by reading and 
deleting its contents regularly, or by storing your messages 
elsewhere for later examination (see Section 6, "Storing Your 
Mail", for various ways to do this). This practice helps keep to 
a minimum the amount of mail you must read through each time you 
look at your mailbox. 

Interactive messages are one-line messages sent, via the 
send_message (sm) command, directly to the recipient's terminal. 
The notice telling you that a mail system message has arrived is 
an interactive message: 

From Moch.ProjCat 08/01/80 09:14 mst Fri: You have mail. 

You cannot receive interactive messages such as this one until 

you issue the accept_messages (am) command. By far the easiest 

way to issue this command is to place it in your start_up 

exec__com segment, so that you accept messages automatically each 
time you log in. See the New Users' Intro - Part II for 

information about exec_coms, the start__up.ec , and accepting and 
sending interactive messages. 

Another useful command to place right at the end of the 
start_up.ec is read_mail (or pr int__mail ) , or the command line 
rdm -list. In this way you can check the contents of your 
mailbox immediately after you log in. 

To learn more about including the mail commands in your 
start_up.ec, see Section 7 of this manual, "Advanced Mail 
Features" . 
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SECTION 2 



THE PRINT MAIL COMMAND 



The print_mail command is a simple interactive command, 
designed for people who will be using the mail system 
infrequently. 

Type the command name print_mail (short name prm). The 
command prints a banner telling you how many messages you have. 
If you have no messages, you are informed of this and returned to 
command level. If you have any messages, the command immediately 
prints your first message: header and then text. It also prints 
a line of information just before the header, noting who mailed 
the message and how many lines of text it contains. 

After each message you are prompted for a response with the 
question "Delete #N?". For example; 



I prm 

You have one message. 

#1 (4 lines) 08/01/80 09:14 Mailed by: Moch.ProjCat 
Date: 1 August 1980 09:14 mst 
From: Moch.ProjCat 
Subject: picnic 
To: Willow. ProjCat 

There will be a meeting at 9:30 on Tuesday to discuss 
plans for the umpteenth annual office picnic. 
Everyone is asked to attend — please inform 
the others in your project. 

print_mail: Delete #1? ! <type response here> 
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six responses are available: 



B ? 

print the list of acceptable responses, and 
then repeat the query 

B yes (y) 

delete the message and go on 

B no (n) 

do not delete the message, and go on 

B reprint (print, pr, p) 

print the message again 

B abort 

delete nothing and return to command level 

B quit (q) 

delete as directed and return to command level 

As soon as you type a response, another message is printed 
(unless you have typed ?, abort, or quit); if you have no further 
messages, a ready message is printed, indicating that you have 
returned to command level. 

If you are in the middle of a long message and you decide you 
don't want to read any more, press the BREAK or QUIT key on your 
terminal. (See the New Users' Intro manual for a description of 
issuing the QUIT signal in this manner.) When the system 
responds with a QUIT message, type the program_interrupt (pi) 
command, which returns you to the print_mail query. You can then 
delete or save the message, and continue to the next message. 

If you supply an incorrect response (for instance, if you 
misspell the response), the command suggests that you type a "?" 
for the list of responses. If you delete a message and then 
decide you still want it, use the abort response to return to 
command level, rather than the quit response; the abort response 
leaves your mailbox just the way it was when you issued the 
pr interna il command. 
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A useful control argument to the print__mail command is -list 
(-Is). It prints a summary of your messages before going on to 
print the first message. Here is a sample for the above message: 



! prm -Is 

YOU have one message. 

Msg# Lines Date Time From Subject: 

1* (4) 08/01/80 09:14 Moch.ProjCat picnic 

<message #1 is printed here> 



This control argument can refresh your memory and save you time, 
especially when used in conjunction with the QUIT signal. 
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SECTION 3 



THE SEND MAIL COMMAND 



The send_mail command provides you with the ability to create 
and send messages. It also gives you the opportunity to examine 
and edit your message before sending it, if you wish. 

The first part of this section presents a review of the most 
basic use of the send_mail command. After reading this part, you 
can go directly to a terminal, write and deliver a message to 
another user, and be returned to command level. When you wish to 
learn more about * the basic send_mail vocabulary of viewing, 
editing, sending, and gaining assistance, you can read on in this 
section. Later sections (5, 6, and 7) describe additional 
capabilities of the Multics mail system. 



BASIC send mail COMMAND 

Enter send__mail by typing the send__mail command (short name 
sdm) and the User_id of the person to whom you are writing. 
(Within the mail system, the User_id is considered one form of 
address, because the mail system uses this information to deliver 
the message to the correct mailbox,) Remember that a User^id 
consists of both a Person_id and a Project_id. After you type a 
newline, send_mail prompts you for the subject of your message: 



j ! sdm Willow. ProjCat j 
I Subject: j 

J . L 

(A subject line gives the recipient a very useful way of 
remembering what the message concerns.) Type in a title and 
another newline directly after this prompt. Now send_mail 
responds with another prompt, indicating that you may proceed 
with your message. 
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! sdm Willow. ProjCat 
Subject: ! and you? 
Message: 



As you type in your message, keep in mind that the # and @ 
characters are always available for correcting or erasing the 
line you are currently working on. 

The simplest way to conclude your message is to type a period 
alone on a line, and then a newline. As soon as you do this, the 
message is sent to the person you specified, and you receive a 
confirming system note that looks like "Mail delivered to 
Willow, ProjCat" . Then a ready message is printed, indicating 
that you have been returned to command level automatically. 

Here is an example of one complete session in send mail. 
Note the use of the # character to correct a mistake Tn the 
message text. 



! sdm Willow. ProjCat 
Subject: ! and you? 
Message: 

! Are you going to the picnic meeting on Thu##uesday? I hope 
! to go, but I don't know if 
! it will be possible. 

• • 

Mail delivered to Willow.Pro jCat . 
r 10:26 0.272 94 



THE REQUEST LOOP 

The send_mail command has several requests that are as useful 
to the new user as to more experienced users. As you see from 
the example above, however, you have had no opportunity to give 
send^mail any requests — you are automatically returned to 
command level when you finish typing in your message. In order 
to issue requests, you must enter the send__mail request loop. 
The request loop, described in "Requests" in Section 1, is a 
repeating cycle consisting of a send_mail prompt, your request, 
and a resulting send_mail action, followed by another prompt. 
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Several ways of entering the send__mail request loop are 
explained in this section. One method is to end your message 
with a "\q" instead of a period. You will be answered with the 
send_mail prompt, indicating that you are in the send_mail 
request loop: 



! sdm Willow. ProjCat 
Subject: I and you? 
Message: 

! Are you going to the picnic meeting on Tuesday? I hope 
! to go, but I don't know if 
! it will be possible. 

I \g 

send mail: 



At this point, you are ready to type any request you wish. 

Other methods for entering the request loop are described in 
"Editing Your Message" just below, and in "send_mail Command 

Control Arguments" at the end of this section. For now, though, 
simply type "\q" as the last line of your message. 



VIEWING YOUR MESSAGE 



The print Request 

The send_mail print (pr) request displays the message text, 
and is preceded by a shortened version of the message header. 
The example message from above is used for illustration: 



send_mail: ! pr 

(2 lines in text): 
Subject: picnic 
To: Willow. ProjCat 

Are you going to the picnic meeting on Tuesday? I 
hope to go, but I don't know if it will be possible. 

send mail: 



Notice that the message text does not appear just the way you | 
typed it in. See "Message Filling" later in this section for a | 
complete explanation. | 
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When you want to see the entire message, header and all, use 
the -header (-he) control argument with print: 

send_mails ! pr -he 

To view only the text of your message, use the -no^header (-nhe) 
control argument: 

send__mail: ! pr -nhe 



The print header Request 

The print_header (prhe) request enables you to see the 
complete header of a message, without its text: 



send_mail: ! prhe 

(1 line in text): 

Date: 1 August 1980 09:14 mst 

From: Moch.ProjCat 

Subject: picnic 

To: Willow. ProjCat 

send mail: 



To obtain just the shortened header, as illustrated for the print 
request above, add the -brief (-bf) control argument: 

send_mail: ! prhe -bf 



EDITING YOUR MESSAGE 

One of the most useful aspects of send_mail is its built-in 
editor. A version of the qedx editor, it allows you to change, 
delete, and add to your message while you remain in send_mail. 
However, you do not need to type "w" before you end your editing 
session — the editor does this automatically. 

The send_mail editor operates like the qedx editor introduced 
in the New Users' Intro - Part I, and explained fully in the Qedx 
Users' Guide. You are strongly encouraged to turn to one or both 
of those manuals, because in this manual only a review of the 
simplest subset of editor requests is given. 
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When you are first typing in your message and you want to 
make changes, type "\f" alone on a line, just as you do in qedx 
when you wish to move from input mode to edit mode: 



Message: 

! There will be a meeting at 11:00# 
! \f 



When you are already in the send_mail request loop and you want 
to enter the built-in editor, you should use the qedx (qx) 
request: 

send__mail: ! qx 

Once you are in the editor, you issue editor requests, as opposed 
to send_mail requests. Here is a list of basic editor requests: 



REQUEST 
P 

d 
a 

s/old/new/ 
s/old/new/p 



DESCRIPTION 

prints the specified line(s) 

prints the line number of the 
specified line 

deletes the specified line(s) 

adds lines of text after the 
specified line 

substitutes every occurrence of 
the first character string with 
the second character string, on 
the specified line(s) 

same as above, but also prints 
the changed line 



EXAMPLES 



d 
a 



2p 
$= 

3d 
2a 



1 3^ 



s/hte/the/ 
l,$s/ll:00/9:30/ 



s/hte/the/p 



If you wish to abort all changes made within the editor, type | 
the qedx request l,$dr on a line by itself. This restores the | 
original message text to the qedx buffer. | 

To leave the send_mail editor, simply type q and you will be 
returned to the send_mail request loop. Note that this q request 
is the editor quit request, not the send__mail quit request (see 
"Quitting" below). 
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Here is an extended example of how an answer to the previous 
message could be constructed. Supplemental comments are 
displayed to the right of the example. Spaces that would not 
necessarily be in an actual session are included here for 
clarity. 



1 i 


sdm Willow. ProjCat 








Subject: ! your talk 








Message : 






1 1 


I thik your talk 




<a first draft> | 


I 


was good. 






I 1 


If you wtanto to @ 




<a first draft> j 


1 I 


If you would like more 


spcef ic 




j 1 
1 1 


comments, let me know. 






1 f 
1 1 


\f 




<enter edit mocie> j 


1 I 


Is/k/nk/p 




<correct one error, > j 




I think your talnk 




< but cause another !> j 


1 1 


s/lnk/lk this morning/ 




<fix second error on > | 








< current line, and > j 








< add more info > j 


1 1 


s/ink/ought/ 




<another change> | 


1 1 






<print entire message> j 




I thought your talk this morning 


• 1 




was good. 




• 1 




If you would like more 


spcef ic 


« I 
• 1 




comments, let me know. 




< — 


1 1 


4p 








If you would like more 


spcef ic 




i 1 


s/spce/speci/p 




<correct another error, > j 




If you would like more 


specific 


< and print the line "> { 


1 1 


3d 




<delete empty line> j 


1 1 


q 




<leave editor> j 




send_mail: ! send 








Mail delivered to Willow. ProjCat 






send mail: ! quit 








r 13:02 0.478 92 







Further editing features are discussed in Sections 5 ("Mail 
Segments") and 7 ("The apply Request"). 
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SENDING YOUR MESSAGE 



Once you are in the send_mail request loop, it is important 
to know the send request — otherwise your message will not get 
delivered. The send_mail command delivers mail automatically 
only when you bypass the request loop by ending your message with 
as described in "Basic send_mail" at the beginning of this 
section. 

The simplest way to use this request is to type send. If you 
entered the send_mail command with an address, as described in 
the beginning of this section, then the message is immediately 
sent to the mailbox of the person you specified on the command 
line. A notice is printed confirming delivery, as well as the 
usual send_mail prompt: 



send_mail: ! send 

Mail delivered to Willow. ProjCat. 

send mail: 



If the message cannot be delivered, you receive immediate notice 
of the cause: 



I 
I 

I send_mail (send): Some directory in the path specified 

I does not exist. >udd>ProjCat>Wilow>Wilow.mbx 

I send_mail (send): The message was not sent. 

send mail: 



The cause here was a missing "1" in the User__id (which you can 
correct with the remove and to requests, described in Section 5). 

You may ascertain that the recipient of your message has read 
the message by supplying the -acknowledge (-ack) request control 
argument with the send request. When the person reads your 
message, you automatically receive an interactive message like 
this one: 



From Willow. ProjCat 08/01/80 15:41 mst Fri: 

Acknowledging your message of 1 August 1980 09:14 est; 
Subject: your talk 
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Another consequence of using -acknowledge with the send request 
is that it adds an extra field to the message header: 



(2 lines in text): 

Date: 1 August 1980 13:02 mst 

From: Merce.ProjDog 

Subject: your talk 

To: Willow. ProjCat 

Acknowledge-To: Merce.ProjDog 



The acknowledgement is sent by the mail system from the 
recipient's mailbox automatically. 



MESSAGE FILLING 



Once you send your message by typing alone on a line 

followed by a newline, the message is automatically reformatted. 
The right margin of the text is adjusted so that no line has more 
than a certain number of characters. This process of message 
reformatting is called FILLING. For example, when user Willow 
reads the text of the picnic message, it looks like this: 



There will be a meeting at 9:30 on Tuesday to discuss 
plans for the umpteenth annual office picnic. Everyone 
is asked to attend — please inform the others in your 
project . 



If you type a message online and then use the qedx editor 
before sending it, the message is filled automatically after you 
exit qedx. See Appendix A for further details on filling in qedx 
within send_mail. 

Within send_mail, the fill (fi) request allows you to fill 
the message text as described above, and to set the line length 
of the filled text. By default, the maximum line length of 
filled text is set at 72 characters. If you prefer, you can 
specify another length with the -line_length (-11) control 
argument followed by the maximum number of characters you want: 



send mail: ! fi -11 50 
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This makes the message text look like this: 



j There will be a meeting at 9:30 on Tuesday to j 

I discuss plans for the umpteenth annual office | 

I picnic. Everyone is asked to attend — please j 

I inform the others in your project, j 

J L 

The send__mail control argument -line^length (-11) also formats 
the text in the manner described above. 



QUITTING 

Leaving send_mail is usually easy; just type "quit" or "q". 
When you have left unfinished business, though, send__mail checks 
to make sure that you really want to exit: 



send_mail: ! q 

send__mail (quit): Message has not been sent, saved, or 
written. Do you still wish to quit? 



If you purposely wish to leave send_mail without sending a 
message, you can avoid send__mail's query with the -force {-fc) 
control argument to the quit request: 



send_mail: ! q -fc 
r 13:07 0.332 116 



As the ready message shows, you are immediately returned to 
command level. 



ASSISTANCE 

The send__mail command has four means of assistance available 
while you are working. 
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The ? Request 

When you forget the name of a request, or which letter is the 
short name for what request, type the ? request. It prints a 
I multi-columnar list of all requests and their short names. Here 
is an abbreviated version of the ? request and response, listing 
only the requests discussed in this section: 



j send__mail: ! ? 






1 Summary of send__requests 


• 
• 




1 quit, q print, pr, p 
1 send qedx, qx 


fill, fi 

pr int_header , prhe 


help i 


1 Type "list_requests" for 
1 requests. 


a short description 


of the 1 


1 send_ma i 1 : 







The list requests Request 



If you want to obtain a brief description of the available 
requests, type the 1 ist_requests (Ir) request. It prints a list 
of all requests, plus a memory- jogging , one-line description of 
each request. The Ir request also provides several lines of 
significant information preceeding the list of requests. Here is 
an example of the list_requests request and response (only the 
requests already discussed in this section are listed): 



send_mail: ! Ir 

Summary of send_mail requests: 

use ".. COMMAND_LINE" to escape a command line to Multics. 
Type "list_help" for a list of topics available to 

the help request. 
Type "help TOPIC" for more information on a given topic. 



quit, q Leave send_mail. 

print, pr, p Print the specified message. 

pr int_header , 

prhe Print the message's header, 

qedx, qx Edit the message, 

fill, fi Reformat text to fit given width, 

help Obtain detailed information on send__mail. 

? Produce a list of the most common requests. 



send mail: 
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In addition, you can specify a topic name with the Ir 
request, and receive a list of all requests which contain that 
topic name. For example, you may want to know what requests 
contain the word "list" in send mail: 



j send_mail: ! 


Ir 


list 






1 list_help, Ih 
1 list_requests, 


Ir 


List 
List 


topics for 
brief info 


which help is available. | 
on send_mail requests. | 


1 send__mail: 











The help Request 

For detailed information on how to use a particular request, 
type "help" followed by the name of the request: 



send_mail: i help quit 

(6 lines follow; 16 in info) 

09/26/82 send_mail request: quit, q 

Syntax: quit {-control_args} 

Function: exits send__mail. 

Control arguments (8 lines). More help? ! yes 

Control arguments: 
-force, -fc 

causes send_mail to exit even though the message has 
been modified since it was last sent, saved, or written. 
-no_force, -nfc 

causes send_mail to query the user for permission to 
exit if the message has been modified since it was last 
sent, saved, or written. (Default) 

send mail: 



The help request is similar to the Multics help command, but it 
is simpler and more restricted. It offers an internal set of 
info segments on every send_mail request, and on selected other 
topics concerning send__mail. For a list of topics, use the j 
list__help request (described below). j 
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I Most of the control arguments accepted by the Multics help 
I command are accepted by the help request. The -brief (-bf) 
1 control argument is particularly useful; it produces a summary of 
j the request, including the syntax line, arguments, and control 
I arguments. For a complete description of the help request, type 
I "help help". 

The help request is a prompting request, asking you at 
several points if you want more information. The example above 
illustrates one of the possible responses to the help prompt: 
I "yes". If you want a list of all the responses that you could 
give while inside the help request, type a "?" in answer to the 
help prompt. 

I If you type the help request with no arguments, you get a 

I response which explains several ways to obtain online 
information. 



The list help Request 

For a list of available info segments on send_mail topics, type 
the list_help (Ih) request. If you specify a topic after the 
request, you receive a list of all send_mail info segments 
pertaining to that topic. For example: 



send_mail: ! list__help print 
Topics available for send__mail: 
print 

pr int__header 
send mail: 



send mail CONTROL ARGUMENTS 

All the control arguments discussed up to this point have 
been request control arguments, added to the request line after 
the request to which they belong — as, for example: 

send_mail: ! pr -nhe or send__mail: ! q -fc 
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The send_mai 1 command itself also has a set of control arguments , 
as noted in Section 1; you include them on the command line, 
after typing "send__mail" and a User_id. Here are two that may be 
useful to you. 

The best method for entering the send^mail request loop is 
via the command control argument -reguest_loop (-rql): 

! send_mail Willow. Pro jCat -rql 



After you are prompted for the 
you may conclude the text with 
with a send_mail prompt: 



subject and text of your message, 
a period, and you will be greeted 



! <text of message> 
1 . 

send mail: 



An interesting and handy control argument is called 
-input_file <path> or -if <path>. This permits you to send a 
regular ASCII segment as a message. For instance, a list of 
picnic foods in a segment named "victuals" can be sent this way: 



! sdm Willow .ProjCat -if victuals 
Subject: ! picnic stuff 

send_mail: I send; q 

Mail delivered to Willow. ProjCat . 

r 16:11 0.291 86 



The segment that you send should contain only the message text, 
because send_mail supplies the message header. 

Notice that when using the -input__file control argument you 

can still provide a subject for the message. Also, you can use | 

the built-in editor or other 5enu__mail requests, because you are j 

put into the send_mail request loop after you provide the message | 

subject. I 
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When sending a message using the -if control argument, the 
message text is not automatically filled. It is assumed that you 
have already formatted the file before sending it. If you wish 
to reformat the file while sending it, use the fill request. 
This request causes the text to be reformatted in the manner 
described in "Message Filling" earlier in this section. For 
example, user Moch.ProjCat sends an input file which is filled to 
the default line length of 72 characters, with the following 
lines: 



sdm Willow. ProjCat -if victuals 
Subject: picnic stuff 

send_mail: fill; send 

Mail delivered to Willow.Pro jCat . 

send mail: 



The -acknowledge (-ack) command control argument provides you 
with a confirmation of your message being read, without you 
having to enter the request loop. 

The send__mail command has many more control arguments. Most 
of them are presented in later sections of this manual. A 
complete list of the available control arguments is in 
Appendix A. 
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SECTION 4 



THE READ MAIL COMMAND 



The read__inail command is a flexible interactive command. It 
is designed to be completely accessible to the novice, and also 
useful for a variety of advanced purposes. 

The first part of this section presents, in brief, the most 
basic use of the command. After reading this part, you can go 
directly to a terminal and perform the simplest tasks of reading 
and discarding one or more of your messages, and returning to 
command level. When you wish to learn more about the basic 
read__mail vocabulary, you can read on in this section. Later 
sections (5, 6, and 7) present additional capabilities within the 
read mail and send mail commands. 



BASIC read mail REQUESTS 

When you type read_mail (short name rdm) , the command prints 
a banner telling you how many messages you have. It then skips a 
line, and types a prompt: 



! rdm 

You have 2 messages, 
read mail: 
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The command waits for you to type a read_mail request in response 
to this prompt. {If you have no mail, a notice is printed 
telling you this, and you are returned to command level.) When 
you type a request, read__mail performs the task you have 
requested and then prompts you again for another request. The 
four most basic requests are: 

B list (Is) prints a heading line, and then one line of 

information about each message. The first 
column contains the message number, denoting 
the position of that message in the mailbox. 



read_mail: ! Is 

Msg# Lines Date Time From Subject 

1* (4) 08/01/80 09:14 Moch.ProjCat picnic 

2 (2) 08/01/80 10:26 Brie.ProjDog and you? 

read mail: 



I B print (pr, p) prints the header and text of the message or 

messages you specify; a message is specified 
by its message number. Type the message 
number directly after the request (e.g., 
print 1). 



read_mail: I pr 2 

#2 (1 line) 08/01/80 10:26 Mailed by: Brie.ProjDog 
Date: 1 August 1980 10:26 mst 
From: Brie.ProjDog 
Subject: and you? 
To: Willow. ProjCat 

Are you going to the picnic meeting on Tuesday? I 
hope to go, but I don't know if it will be possible. 
(2) 

read mail: 
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B delete (dl, d) deletes the message or messages you specify. | 

Type the message number directly after the 
request . 



1 read__mail: 


1 
• 




1 read^mail: 






B quit (q) 




returns you to command level. 


1 

1 read mail: 
1 r 14:22 0. 

1 


1 

445 


1 

q 1 
325 1 

1 



LISTING AND PRINTING 



The list Request 

The list (Is) request serves as a handy reference tool in 

information about each of your messages; this aids in deciding 
what you want to do with them. Here is a sample list summary 
from a mailbox with four messages: 



Msg# Lines Date Time From Subject 

1* (4) 08/01/80 09:14 Moch.ProjCat picnic 

2 (2) 08/01/80 10:26 Brie.ProjCat and you? 

3 (2) 08/01/80 13:02 Merce .Pro jDog your talk 

4 (27) 08/01/80 16:47 Edgar .Pro jDog comments y<MORE> 



The Message Number column shows the position of each message in 
this mailbox at this time. The Lines column includes only the 
lines of text in a message, not the number of header lines. The 
date and time that the message was sent to you are recorded also, 
as is the person who sent it to you. If the sender has included 
a subject, the Subject column includes as much of the subject as 
will fit on the rest of the line. The asterisk next to a message 
number indicates which is the current message. 
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You can use the list request to give you a summary line about 
a single message; simply follow the request name with a message 
number: 



i read__mail: 


! Is 4 








1 Msg# Lines 


Date 


Time 


From 


Subject j 


1 4* (27) 


08/01/80 


16:47 


Edgar .Pro jDog 


comments y<MORE>| 



At the end of the summary line, "<MORE>" indicates that the title 
is longer than can fit on the line. Also notice the asterisk 
after message #4 listing a message makes it become the current 
message. 



The print Request 

As noted above, the print (pr, p) request prints both header 
and text of the message or messages you specify. With a summary 
of messages in front of you, you can use the print request more 
effectively. If you have many messages, you can choose which 
message to print first, or you can decide not to read certain 
ones at this time. 



MESSAGE SPECIFIERS 

In order to print your messages so far, you have issued the 
print request followed by a message number. A message number is 
one of several MESSAGE SPECIFIERS: ways of indicating which 
messages you want to see. 



Keywords 

Another kind of message specifier is the keyword. These 
keywords are used just like message numbers: 





current (short name c) 


■ 


next (n) 


■ 


previous (p) 


B 


first (f) 


B 


last (1) 


B 


all (a) 
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When you type "current" directly after the print request ("pr 
current" ) , you get the message that is currently being worked on 
by the read_mail command. The current message is always message 
#1 at first, and it shifts when you issue a request that deals 
with some other message; for example, when you first enter 
read__mail, message #1 is the current message, but when you type 
"print 2" then message #2 becomes the current one. You can also 
type simply "print" to see the current message. 

The "next" and "previous" keywords refer to the messages 
relative to the current message, so they shift as the current 
message shifts. The "first" and "last" keywords operate on the 
first and last remaining messages in the mailbox. 



There are also several ways to print more than one message 
at a time. When you know exactly which messages you want to see, 
you may type several message numbers separated by spaces: 

! p 3 1 4 

The messages are printed in the order you specify. 

If you want to see several messages in a row, you can specify 
a range by typing a message specifier for the earliest message 
you want, then a colon, and then a message specifier (no 
intervening spaces) for the last message you want, like this: 

! pr 2:4 

This prints messages #2, #3, and #4 for you. The keyword "all" 
prints all the undeleted messages in your mailbox. 

When specifying a range, you can use any combination of the 
above-mentioned message specifier types. For example, assuming 
there are four messages in your mailbox and message #1 is the 
current message, all of the following expressions yield the same 
result: 



For further information on message specifiers, see Appendix A. 



Ranges 



print f:last 
pr c:4 
p all 

print 1:3 last 



p 1:4 

pr 1 2 3 4 
pr c:last 
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print REQUEST CONTROL ARGUMENTS 

In some cases you know that you will not want to keep a 
I particular message after you read it. The -delete (-dl) control 
argument is useful then: 

read__mail: ! p first -dl 

This request line is equivalent to: 

read_mail: ! p first;d first 

After the message you specify is printed out for you, it is 
deleted. 

If you wish to bypass printing the full header when reading a 
message, you can supply the print request with its -no_header 
(-nhe) control argument. A shortened header is then printed 
before the text of the message, including only essential 
information: 



read_mail: I pr 3 -nhe 

#3 (2 lines) 08/01/80 13:02 Mailed by: Merce.Pro jDog 
From: Merce .Pro jDog 
Subject: your talk 

I thought your talk this morning was good. If you 
would like more specific comments, let me know. 
(3) 

read mail: 



The first line of the shortened header includes the date and time 
the message was sent to this mailbox, which can be different from 
when the message was written or first sent. 
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There may be times when you need more information about a 
message than you can get from the list request, but you don't 
want to read through the text of the message. The read_mail 
request pr int__header functions just as the send__mail print_header 
request does: 



read_mail: ! prhe 3 

#3 (2 lines) 08/01/80 13:02 Mailed by: Merce.Pro jDog 
Date: 1 August 1980 13:02 mst 
From: Merce.Pro jDog 
Subject: your talk 
To: Willow. ProjCat 

read mail: 



The need for the print_header request occurs more frequently as 
you (or the people sending you messages) learn to send messages 
in more complex ways. Several of the additional read_mail and 
send_mail requests add extra header fields to message headers. 



REPLYING TO MESSAGES 

In many cases the most efficient way of responding to the 
messages you receive is with the reply (rp) request. When you 
supply the reply request with one message specifier, you are 
immediately placed in send_mail and prompted for the text of your 
reply: 



read_mail: ! rp 2 
Replying to Brie.ProjDog 
Message: 



The subject of your message is automatically taken from the 
Subject field of the message you are replying to: 

Subject: Re: and you? 

unless you specify another subject with the send_mail subject 
request. You can reply to only one message at a time. 

To send the reply, simply type a period, as you would a 
regular message. Because you create the reply using send_mail, 
you can also type "\q" to enter the send_mail request loop. When 
you leave send__mail (via the quit request or ".")/ you are 
returned to read mail. 



4-7 



CH23-01 



When reply is used, the In-Reply-To field is added to the 
message header of the reply: 

1 In-Reply-To: Message of 1 August 1980 10:26 mst from Brie.ProjDog 

This tells the recipients which message is being answered. Many 
of the send__mail command control arguments can be used on the 
reply request line. See Appendix A for details on this request. 



FORWARDING A MESSAGE 

You have the option of sending on copies of the messages you 
I receive, with the forward (fwd, for) request. Follow the request 
name with the message specifier and the address(es) of 
recipients: 

read_mail: ! fwd 1 Scout .Pro jCat When you use forward, 
several new fields are added to the message header: 



i Redistr ibuted-Date 


: 1 August 1980 15:32 mst | 


1 Redistributed-By : 


Willow . Pro jCat j 


1 Redistr ibuted-To: 


Scout .Pro jCat j 



This indicates to recipients how the forwarding was performed. 



DELETION AND RETRIEVAL 



The delete Request 

Once you have read a message and kept it in this mailbox as 
long as you want, you can delete it from your mailbox easily with 
I the delete (dl, d) request and a message specifier. In fact, you 
may include several message specifiers in your delete request 
line: 



read_mail: ! d 4 2 
read mail: 
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Notice that message specifiers may appear in any order, and they 
may have any number of spaces separating them. When you issue 
the list request after deleting messages, you receive a summary 
of the remaining messages, still with their original message 
numbers: 



" r 

read__mail: I Is | 

Msg# Lines Date Time From Subject: | 

1 (4) 08/01/80 09:14 Moch.ProjCat picnic | 

3* (2) 08/01/80 13:02 Merce.ProjDog your talk | 

read mail: 



Message numbers do not get reassigned to the remaining messages 
until you quit the read__mail command. 

If you try to delete a message which hasn't been listed, 
printed, saved, or written, you are queried with a prompt: 



j read__mail: ! dl 3 




j read mail (delete): 


Message #3 has not been processed. j 


1 OK to delete? ! 


no 1 


j read_mail (delete): 


No messages deleted. j 


1 read_mail: 









If you answer "no" to the query, no messages are deleted, as in 
the example above. If you answer "yes", the message is deleted. 
There is no acknowledgment of the deletion; you are simply 
prompted for another request* 



When you have deleted each message in the mailbox, you are 
sent the notice: 

All messages have been deleted. 
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The retrieve Request 

Deleted messages are not really deleted. They are merely 
"marked for deletion". They actually remain in the mailbox until 
you leave the mail system (with the quit request) and return to 
command level. If you have not yet left read__mail, you can 
return your deleted messages to your mailbox by issuing the 
retrieve (rt) request with the message numbers of your deleted 
messages: 



j read__mail: 


! dl 


4 1 


1 read__mail: 


! rt 


2 4 1 


1 read_mail: 













Because message numbers are not reassigned when a message is 
deleted, you simply type the message number that that message had 
before you marked it for deletion. Other forms of message 
specifier should not be used. 



To check on the correct message number of a deleted message, 
j type the list request with the - include_deleted (-idl) control 
argument. Assume the current message is message #2, and observe 
the following: 



read_ 


_ma i 1 : 


read_ 


ma i 1 : 


Msg# 


Lines 


1 


(4) 


2! 


(2) 


3* 


(2) 


4 


(27) 



Date Time From 

08/01/80 09:14 Moch.ProjCat 

08/01/80 10:26 Brie.ProjDog 

08/01/80 13:02 Merce .Pro jDog 

08/01/80 16:47 Edgar . Pro jDog 



Subject: 
picnic 
and you? 
your talk 
comments y<more> 



read mail: 



The -include_deleted control argument to the list request lists 
all messages, including deleted ones. An exclamation point 
beside a message number signifies a deleted message. Note that 
once message #2 is deleted, the current message automatically 
becomes #3. 
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The print request also has the ~idl control argument, j 
performing the parallel operation with deleted messages. If 
message #2 has been deleted, then this request line: 

read_mail: I p 1:3 

prints only messages #1 and #3, but this line: 



read_mail: ! p 1:3 -idl | 
prints messages #1, #2, and #3. 

* 

Remember: no message is truly gone until you issue the quit 
request. Once you leave read_mail, though, you can no longer 
retrieve deleted messages. 



QUITTING 

All you need to do to leave read_mail is type quit, or just 
q. But even the quit request has a couple of special features. 

If you have been trying out various combinations of lists, 
message specifiers, deleting, and retrieving, you may be confused 
and worried about quitting and possibly deleting messages that 
you want to keep. Now is the time to use the -no_delete (-ndl) | 
control argument of the quit request: 



I <too many requests> | 

I I 
I read_mail: ! q -ndl | 

j r 11:43 0.343 133 | 
J L 

This discards all modifications that you have made during this 
session with read_mail. Next time you enter read__mail you will 
find your mailbox just the way you found it this time (plus any 
messages that have arrived since then). This control argument 
can be better than aspirin. 
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Sometimes when you issue the quit request you receive a note 
like this: 



j read_mail (quit): A new message has arrived. Do you j 
I still wish to quit? | 

J L 

You must answer either yes, in which case you are returned to 
command level, or no, which gives you another read__mail prompt. 
If you use the -force (-fc) request control argument with quit: 



j read_mail: ! q -fc 
I r 11:43 0.0703 286 

J 

you are returned to command level with no questions asked. 



ASSISTANCE 

The read_mail command has several means of assistance 
available while you are working. 



The ? Request 

When you forget the name of a request, or which letter is the 
short name for what request, type the ? request. It prints a 
I multi-columnar list of all requests and their short names. Here 
is an abbreviated version of the ? request and response, listing 
only the requests discussed so far in this section: 



j read_mail: 


! ? 




1 Summary of 


read_mail 


requests: j 


1 help 


print, pr 


, p delete, dl, d reply, rp | 


1 quit, q 


list. Is 


retrieve, rt j 


I Type "list_ 


_requests" 


for a short description of the | 


I requests. 






1 read_mail: 
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The list requests Request 



If you want to obtain a brief description of the available 
requests, type the list_requests (Ir) request. It prints a list 
of all requests, plus a memory- jogging, one-line description of 
each request. The Ir request also provides several lines of 
significant information preceeding the list of requests. Here is 
an example of the list__requests request and response (only a few 
of the requests already discussed in this section are listed): 



read__mail: ! Ir 

Summary of read_mail requests: 

use ".. COMMAND_LINE" to escape a command line to Multics. 
Type "list__help" for a list of topics available to 

the help request. 
Type "help TOPIC" for more information on a given topic. 

quit, q Leave read_mail. 

print, pr, p Print the specified messages, 

list. Is List the specified messages, 

delete, dl, d Delete the specified messages. 

read mail: 



In addition; you can specify a topic name with the Ir 
request, and receive a list of all requests which contain that 
topic name. For example, you may want to know what requests 
contain the word "list" in read mail: 



read__mail: ! Ir list 

list. Is List the specified messages. 

list_help, Ih List topics for which help is available. 

list_requests, Ir List brief info on read_mail requests. 

read mail: 
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The help Request 

For detailed information on how to use a particular request, 
type "help" followed by the name of the request: 



read__mail: ! help quit 

(6 lines follow; 27 in info) 

09/28/82 read_mail request: quit, q 

Syntax: quit {-control__args} 

Function: deletes any message marked for deletion and 
exits read_mail. 

Control arguments (7 lines). More help? ! yes 

Control arguments: 
-delete, -dl 

specifies that messages marked for deletion should indeed 
be deleted before exiting. (Default) 
-no_delete, -ndl 

specifies that messages marked for deletion are not to be 
deleted. 

7 more lines. More help? ! no 
read mail: 



The help request is similar to the Multics help command. It 
offers an internal set of info segments on every read_mail 
I request, and on selected other topics concerning read_mail. For 
j a list of the topics, use the list__help request described below. 

The help request is a prompting request, asking you at 
several points if you want more information. The example above 
illustrates two of the possible responses to the help prompt, 
I "yes" and "no". If you want a list of all the responses that you 
could give while inside the help request, type a ? in answer to 
the help prompt, 

I Most of the control arguments accepted by the Multics help 

I command are accepted by the help request. The -brief (-bf) 
I control argument is particularly useful; it gives you a summary 
I of the request, including the syntax line, arguments, and control 
I arguments. For a complete description of the help request, type 
I "help help". 
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If you type the help request with no arguments, you get a 
response which explains several ways to obtain online 
information. 



The list help Request 

For a list of available info segments on read^mail topics, type 
the list_help (Ih) request. If you specify a topic after the 
request, you receive a list of all read^mail info segments 
pertaining to that topic. For example: 



read^mail: ! list_help print 
Topics available for read_mail5 
print 

pr int_header 
read mail: 



read_mail CONTROL ARGUMENTS 

All the control arguments discussed up to this point have 
been request control arguments, added to the request line after 
the request to which they belong — as, for example: 

read__mail: ! pr 4 -nhe or read__mail: ! q -fc 

The read_mail command itself also has a set of control arguments; 
you include them on the command line, just after typing 
"read mail". 
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One command control argument may be of particular use to you 
at this point. By now you may rely on the list request so much 
that you would like to see a list of your messages as soon as you 
enter read_mail. In this case, use the -list (-Is) control 
argument : 



! rdm -Is 

You have 4 messages. 

Msg# Lines Date 
1* (4) 08/01/80 

2 (1) 08/01/80 

3 (2) 08/01/80 

4 (27) 08/01/80 

read mail: 



After the list summary is printed, you are prompted for your 
first request. 

You may wish to have your messages printed with the brief 
type of header each time you issue the print request, rather than 
seeing the complete header. To have this as your default action, 
I add the -no__header (-nhe) command control argument to the 
read_mail command line: 

! rdm -nhe 

For those times that you do wish to see the full header, you can 
specify the -header (-he) request control argument on the print 
request line: 

! read_mail: p -he 

The read__mail command has many more control arguments. Most of 
them are presented in later sections of this manual. A complete 
list of the available control arguments is in Appendix A. 



Time From 

09:14 Moch.ProjCat 

10:26 Brie.ProjDog 

13:02 Merce.ProjDog 

16:47 Edgar .ProjDog 



Subject 
picnic 
and you? 
your talk 
comments y<MORE> 
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SECTION 5 



MORE ON SENDING A MESSAGE 



With the send_mail command, you have learned how to create, 
edit, and send a message to one person. The first part of this 
section describes various ways of sending a message to as many 
users as you like. 

Most of the requests described below affect the message 
header, because message headers contain the entire "history" of 
their messages, including information such as who sent the 
message and all the people who received it. So far, when you 
have sent messages, the mail system has gathered this information 
and automatically compiled the full header, with you adding only 
the title. In the second part of this section, you learn ways of 
modifying the header yourself. 



SENDING TO SEVERAL PEOPLE 



The to Request 

The best way to send your message to several people is to use | 
the to request in conjunction with the send request. There are 
many times when you already know all the people who should read a 
particular message. Perhaps it is also desirable that the 
recipients know who else receives the message. The to request 
lets you create a list of recipients for the message, which you 
can add to at any point: 

send_mail: to Edgar .Pro jDog 
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When your message is completely ready to go, you just type the 
send request with no addresses^ and the message gets delivered to 
all the people you've listed: 



j send_mail: 


to Edgar .Pro jDog j 


1 sena mai i s 


^otner reQuests^ 1 


1 send__mail: 


to FNewton. Pro jDog j 


1 send_mail: 
1 Mail delivered 
1 Mail delivered 
1 Mail delivered 


send I 
to Willow. ProjCat. | 
to Edgar .Pro jDog. j 
to FNewton. Pro jDog. j 


1 send_mail: 





You may also type "to" without any addresses, to obtain the 
complete list of recipients: 



send_mail: to 

To: Willow. ProjCat , Edgar .Pro jDog, FNewton. Pro jDog 
send mail: 



Now if you type the print_header request you will see an expanded 
To field in the message header: 



send_ma i 1 : pr he 

(4 lines in text): 
Date: 1 August 1980 09:14 mst 
From: Moch. ProjCat 
Subject: picnic 

To: Willow. ProjCat , Edgar .Pro jDog, FNewton. Pro jDog 
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The send Request 



The most obvious way to send one message to several people is 
to use the send request several times: 



send_mail: send Edgar .Pro jDog 
Mail delivered to Edgar .Pro jDog. 

send_mails send FNewton .Pro jDog 
Mail delivered to FNewton. Pro jDog. 

send mail: 



This certainly works, and if you keep remembering more people to 
send the message to after you've already sent it, this is the 
quickest way. However, the fact that this message has been sent 
to two people does not appear in anyone's message header. You 
are the only person who knows all the people who received this 
message, when you use the send request. 

Most requests that accept address arguments at all accept as 
many addresses as you want to type. A more efficient way of 
sending a message to the users listed above is: 



send_mail: send Edgar . Pro jDog FNewton , Pro jDog 
Mail delivered to Edgar .Pro jDog. 
Mail delivered to FNewton .Pro jDog. 

send mail: 



In this situation, the default is that if the message cannot be 
delivered to one of the specified recipients (because of a 
misspelled address, for instance), it is not sent to any 
recipients. To reverse this default action, type the -no abort 
control argument to the send request; now the message wTll be 
sent to all valid addresses. 

Of course, you can accomplish the same result as above by 
typing the names of all the recipients on the send_mail command 
line: 



send_mail Edgar .Pro jDog FNewton .Pro jDog j 
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The cc Request 

You also have the option of sending "carbon copies" of a 
message to users who are not directly involved in the topic you 
are writing about, but who nevertheless are interested in or 
otherwise connected with the topic. The cc request thus 
simulates letter and memo procedure in a typical office 
environment . 

Use this request just like the to request: 



j send__mail: 


cc Scout .Pro jCat Merce.Pro jDog j 


1 send_mail: 


cc 1 


1 cc: Scout 


.ProjCat, Merce.ProjDog | 


1 send_mail: 









You can also type the request without addresses, to see whom you 
already have on your cc list. 



These secondary recipients will receive the message as soon 
as you type the next send request with no addresses: 



send_mail: cc Scout .Pro jCat Merce.ProjDog 

send__mail: send 
Mail delivered to Scout .ProjCat . 
Mail delivered to Merce.ProjDog. 
Mail delivered to Edgar . Pro jDog . 
Mail delivered to FNewton . Pro jDog. 

send mail: 



As the example shows, all recipients from all lists receive the 
message when you type the send request with no addresses, even if 
they have already received a copy. Thus, when using the to and 
cc requests, you should not issue a send request until after you 
have included all recipients. 

When you do type send with addresses, only the people who are 
listed on this send request line receive the message at this 
time, even if you also have unprocessed lists of other 
recipients. 



5-4 



CH23-01 



To see how the cc request changes a header, type the 
pr int__header request: 



j send__mail: prhe j 

I {4 lines in text): | 

I Date: 1 August 1980 09:14 mst j 

j From: Moch.ProjCat j 

I Subject: picnic j 

J To: Willow. ProjCat, Edgar .Pro jDog, FNewton.ProjDog j 

I cc: Scout .ProjCat, Merce. Pro jDog | 

I send_mail: j 
J L 

The cc field has been added to the header information. 

RELATED HEADER MODIFICATIONS 

Once you are using the mail system for much of your written 
communication, you will probably start wishing that you could 
make more changes, not just in the text of your messages, but in 
the headers. What if you accidentally include an inappropriate 
address in the To field? How can you give an edited version of 
one message to a completely new set of people? Below are several 
more requests that help you tailor one message to suit varying 
requirements. 



The remove Request 

Almost as important as knowing how to add recipients for a 
message is knowing how to delete a recipient's name, before you 
send the message. This is one of several tasks that the remove 
request can easily accomplish for you. 

The simplest way to delete addresses from lists of recipients 
is to type the remove (rm) request followed by all the addresses 
of those people whom you do not want to receive the message: 

send_mail: rm FNewton.ProjDog Scout .Pro jCat 

This request deletes FNewton and Scout from all lists in which 
they appear (if you had placed FNewton.ProjDog on both the To and 
the cc lists by mistake, both occurrences of that User_id would 
now be deleted). The remove request control argument -all (-a): 

send_mail: rm -all 

removes all addresses from the To and cc lists. 
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To be more specific as to which field you wish to delete 
from, you can use one of the remove control arguments. They are 
named after header fields, although the control arguments are, of 
course, in lowercase. For instance, to delete an address from 
only the cc field, this is the correct request line to type: 

send__mail: rm -cc Scout .Pro jCat 

Another remove control argument allows you to delete all 
addresses from the given field; use the -all (-a) control 
argument after the appropriate field control argument: 

send_mail: rm -cc -all 

This also removes the cc field from the header. 

If you become confused at any time about what you have done, 
remember that you can check the contents of any list by typing 
just the original request with no addresses (to or cc) or you can 
examine the entire header with the print_header request. 



The subject Request 

The title of a message, in the Subject field, may be both 
viewed and changed with the subject (sj) request: 



j send_mail: subject <viewing the title> j 

I Subject: picnic j 

I send_mail: sj meeting for picnic <changing the title> j 

I send__mail: | 
J L 

Following the subject request with a new title automatically 
deletes the previous title. In order to entirely erase the 
Subject field, use the remove request with the -subject (-sj) 
control argument: 

send_mail: rm -sj 

In general, though, people appreciate seeing the subject of the 
messages they receive. 
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The from Request 

Although with you as the sender of a message, your User id 
must be present somewhere in the header, you may modify what is 
in the From field, with (what else?) the from request. This 
request is also useful for including several names or User_ids: 

send^mail: from Willow.Pro jCat Scout .Pro jCat 

when more than one person is responsible for the message. 

When you change the From field, a new field is automatically 
added to the header — the Sender field — so as to indicate who 
actually delivered the message to this mailbox: 



I 

(1 line in text) : j 

Date: 1 August 1980 17:11 mst | 

From: Willow. ProjCat , Scout .Pro jCat j 

Subject: that meeting j 

Sender: Willow. ProjCat j 

To: Moch. ProjCat | 



As with the other requests, issuing the from request alone gives 
you a look at what is currently in the From field. To remove the 
entry, use the "remove -from -all" request line; in this case, 
your User_id replaces the previous entries, and the Sender field 
is deleted from the header. 



The - comment Control Argument 

You can add information to the recipients' addresses in much 
the same way that you use the from request to supplement your own 
User__id. The send_mail command and any request that accepts 
addresses also accepts the -comment {-com) control argument, | 
followed by a quoted character string. Here are two examples: 



I sdm Moch. ProjCat -comment FYI j 

I 

! I 

I send__mail: from Willow. ProjCat -com "Pil Willow" | | 
J L 

Quotation marks are unnecessary for comments without blanks or 
punctuation marks, as in the first example above. 
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The resulting comment is placed in parentheses within the 
header, next to the address: 



(3 lines in text): 
Date: 1 August 1980 16:21 mst 
From: Willow. Pro jCat (Pil Willow) 
Subject: I can't go 

Sender: Willow. ProjCat , Scout .Pro jCat 
To: Moch. ProjCat (FYI) 



If you delete the commented address, any following comments are 
also deleted. 
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SECTION 6 



STORING YOUR MAIL 



The read_mail and send_mail commands have in common a group 
of requests that can store your mail in several types of segment, 
depending on how you plan to use the messages. Although there 
are slight differences between the read_mail and send_mail 
versions of the requests discussed in this section, the functions 
are the same for both. 



YOUR LOGBOX 

Just as every Multics user creates a personal mailbox for 
collecting incoming messages, everyone can have a default logbox 
made in which to log or keep messages. With this extra mailbox 
you can more thoroughly examine messages at your convenience, and 
yet keep your regular mailbox clear for new messages. 

The logbox operates just like your regular mailbox. When you 
log messages from your personal mailbox into your logbox, the 
complete header as well as the text of each message is logged, 
ready to be examined. The only differences are that the logbox 
has a different name, and your mail does not get delivered 
directly to the logbox — in fact, no users other than you are 
allowed to place mail in your logbox unless you give them 
permission by changing the extended access modes (Appendix B). 



The log Request 

As soon as you first use the log request (in either send_mail 
or read_mail), you receive a system note letting you know your 
logbox is being created. Its pathname is: 



>udd>Pro ject_id>Person_id>Person__id . sv .mbx 



Notice the suffix ".sv.mbx" as part of the logbox name. You will 
probably never need to use this pathname, though, because in both 
read_mail and send_mail the log request delivers messages to your 
logbox a J- omatically . 
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FROM read_mail 

When you are in read_mail, and you wish to place copies of 
some messages into your logbox, type the log request, and message 
specifiers to indicate which messages you wish to log: 

read_mail: ! log 2 4 

If you would like your logged messages to be deleted from your 
regular mailbox, you may use either the delete request or the 
-delete (-dl) request control argument of the log request: 

read_mail: ! log 2 4; dl 2 4 OR read__mail: ! log 2 4 -dl 

You may also log already deleted messages (as long as you have 
not exited from read_mail since you deleted those messages!) by 
I using the log -include_deleted (-idl) request control argument. 
Assuming message #1 has been deleted, this request line: 

I read_mail: ! log 1:4 -idl 

logs all four of the indicated messages. You may include the 
j -delete request control argument along with the -idl request 
control argument here: 

I read_mail: I log 1:4 -idl -dl 

which deletes the remaining undeleted messages (messages #2, #3 
and #4) within that range. 



FROM send_mail 

Inside send_mail, you may log a copy of the message you are 
creating simply by typing the log request: 

send__mail: I log 

No message specifiers or control arguments are necessary here, 
because you have only one message in send_mail at a time. 

You can also direct the send_mail command to log messages by 
adding the send__mail -log control argument to the command line as 
you enter: 

! sdm Willow. ProjCat -log 

By including -log on the command line, you are also adding your 
own User id to the cc header field. 
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Examining Your Logbox 



Because your logbox is one form of mailbox, you use the 
read_mail command to examine its contents. To specify that you 
want to see the logbox, include the -log command control argument 
after the command name, with any other command control arguments 
you want: 

! rdm -log -list 

The -log control argument causes read_mail to read only the 
contents of the logbox. All read^mail requests and control 
arguments are available for your use. 



ADDITIONAL MAILBOXES 



The save Request 

The save request enables you to "file" your messages by 
topic, anywhere that you have access. This request creates extra 

mailboxes whenever and wherever you need them, and then, like the 
log request, stores the specified messages in whichever mailbox 
you indicate. This kind of mailbox is called a savebox; its 
pathname is: 

>udd>Wor k i ng_Di rector y>Name . sv . mbx 

where "Wor king_Directory" is the directory you are currently in, j 
and "Name" is chosen by you. User Willow's "outgoing" savebox, j 
in her "canine" directory, has this pathname: 

>udd>Pro jCat>Willow>canine>outgoing. sv.mbx 



WITHIN send_mail 

To create your first savebox for a message you are sending, 
type a save request line as if the desired savebox already 
existed. Following the send_mail prompt, type "save" and the 
pathname you have chosen for the new mailbox: 

send m.ail: 1 save picnic info 

The mail system automatically adds on the ".sv.mbx" suffix and 
then verifies your intentions with this message: 



i send_mail (send): >udd>ProjCat>Willow>picnic__info. sv.mbx not j 
j found. Do you wish to create it? | 

J I 
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Answer "yes", and a copy of your message is now stored in your 
new "picnic__inf o" savebox. 

If you know before you even enter send__mail that you will 
want to save the message you are about to create, you can enter 
send_mail with the -save <path> (-sv <path>) control argument to 
direct the coming message to the named savebox: 

! sdm FNewton .ProjDog -save picnic__info 

As with the send_mail -log control argument, your User_id is 
placed in the cc header field, and a copy is saved in the 
specified savebox whenever the message is sent. 



WITHIN read mail 



When you are in read__mail, you receive the same response as 
in send__mail from the mail system, when you use the save request 
with a new savebox name. In read_mail, though, you should supply 
message specifiers before typing the savebox name, to make clear 
which message or messages you wish saved: 

read_mail: ! save 2 5 picnic_info 

The read_mail save request allows the use of a -delete (-dl) 
request control argument: 



read_mail: ! save 2 5 picnic_info -dl 



so that you can clear your regular mailbox of messages as soon as 
they have been placed elsewhere. It also allows the 
I -include_deleted {-idl) request control argument, described above 
in "The log Request". 



The send Request 

Among its many other features, the send request includes the 
two control arguments -log and -save <path>. These request 
control arguments perform the same actions to the messages 
specified on the send request line as do their request namesakes. 
For example, this request line: 

send_mail: ! send Scout .ProjCat -save picnic__info 

sends the message to Scout .Pro jCat and saves a copy in the 
sender's picnic_inf o . sv .mbx savebox, just as a separate save 
request would do. 
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EXAMINING OTHER MAILBOXES 



Your Saveboxes 

You can examine one of your saveboxes in a read__mail command 
line, giving the name of the savebox as the argument: 

rdm picnic_info 

This places you inside your picnic_inf o. sv.mbx savebox, ready to 
read the messages you have stored here. The ".sv.mbx" suffix is 
added automatically. 

There is one exception to the above method of examining 
saveboxes. If you type this line and you have a mailbox with the 
same name (i.e., picnic_inf o .mbx) , you will be placed inside your 
picnic^inf o.mbx mailbox. To avoid this kind of confusion, give 
your saveboxes and mailboxes different names. However, if you 
have a savebox and a mailbox with the same name, you can enter 
you savebox in the following way: 

rdm picnic_info. sv.mbx 

Another way to look at one of your saveboxes is to use the 
-save <path> (-sv <path>) control argument in a read__mail command 
line, giving the name of the desired savebox as the <path>: 

rdm -save picnic_info 



Other People' s Mailboxes 

You also have access to read and delete any messages that you 
have sent to other users' mailboxes. To do this, issue the 
read__mail command with an address on the command line. The 
address can be a User_id or the pathname of the mailbox you wish 
to examine: 

rdm Moch.Projdog OR rdm >udd>Pro jDog>Moch>Moch.mbx 

Sometimes an address can be ambiguous; if this is the case, you 
can clarify the address by using one of two address control 
arguments, -user <User_id> or -mailbox <path> (-mbx <path>) like 
this: 

prm -user Moch.BCD OR prm -mbx >udd>BCD>Moch>Moch.mbx 
The ".mbx" suffix is assumed if you do not type it. 
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MAIL SEGMENTS 



Although the mail system itself offers you an impressive 
range of editing, storage, and distribution capabilities, you may 
find it very useful to be able to treat groups of messages as 
standard ASCII segments. You are then free to manipulate 
I messages as you do other segments, to order printed copies, and 
to edit and add comments to any part of the message easily. When 
you use one of the requests described below to- create a mail 
segment, standard access rules apply, because they are standard 
segments . 



The append Request 

When in read__mail, place messages into a segment with the 
I append (app) request, appropriate message specifiers, and the 
name of a segment: 

read_mail: append f:3 canine 

Unless you have previously created it, this causes the segment 
"canine .mai 1 " to be created in your directory, after an inquiry 
from read_mail to make sure this is what you had in mind. If the 
segment already exists, these messages are added to the end of 
the segment. In read_mail you can use the -delete (-dl) request 
control argument with append to delete the original message, as 
you can with the other requests discussed above. 

In send_mail, simply type the request and pathname (the 
".mail" suffix is added automatically): 

send_mail: append canine 

The send_mail command also questions you about this segment if it 
has not yet been created. 

Using one of these segments is just like using any regular 
segment -- but remember that pathnames of all mail segments end 
with the ".mail" suffix. When outside the mail system, be 
careful not to type "canine" when you mean "canine. mail" . 



The write Request 

{ The write (w) request is identical to the append request, 

with two additions. It has a -truncate (-tc) request control 
argument, which enables you to empty an existing mail segment of 
any previous contents before refilling it. There is also the 
-extend request control argument that adds to the existing 
segment, just as the append request does. This control argument 
represents the default action of the request. 
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The preface Request 

The preface (prf) request is very similar to the append | 
request, except that messages get added at the beginning of the 
segment specified, rather than at the end of the segment. This 
is useful for creating segments in which you want your newest 
messages to appear first. 
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SECTION 7 



ADVANCED MAIL FEATURES 



Many of the mail system components already discussed, such 
as control arguments on the command line, message editing, and 
powerful request language, also have additional features that 
enable you to use the read__mail and send_mail commands to meet 
more specialized requirements. These advanced techniques make 
use of command level capabilities from within the mail system. 



ABBREVIATIONS 

Within read_mail and send__mail, you can create abbrevs for 
request lines that you use frequently. These abbrevs can be 
expanded at your discretion. On the read_mail and send_mail 
command lines, the -abbrev (-ab) control argument turns on the 
abbrev process. In the request loop of read_mail and send_mail, 
the abbrev request acts in the same manner. 

For example, you may forward mail frequently to 
Merce.ProjDog. Create the following abbrev at command level: 



! i 

I .a fwm forward c Merce.ProjDog | 

J L 

In read_mail, type the following to send the current message 
to Merce.ProjDog: 



read_mail: • abbrev 

read_mail: ! fwm 

Mail delivered to Merce.ProjDog 

read mail: 
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You can create an abbrev profile specifically for use within 
the mail system with the -profile (-pf) control argument. (A 
profile is a special segment in your home_dir containing your 
abbrevs.) This is helpful if, for example, you want to use the 
same short name "quit" for two different abbrevs: one within the 
mail subsystem, and one at command level. To specify the use of 
the profile mail system, prof ile, type the following request line 
while in read maTl: 



i read_mail: ! abbrev -profile [e hd]>mail_system | 
J L 

You will now use mail__system. prof ile until you either quit 
read_mail, turn off the abbrev processor, or change to another 
profile. You can change profiles as often as you wish within the 
mail subsystem. 

If you use a separate abbrev profile regularly, you may want 
to add the profile to your read__mail or send_mail abbrev. To use 
a special profile within read_mail automatically, create an 
abbrev similar to the following: 



j .ab Rdm do "read__mail -abbrev -profile [hd]>mail_system j 
I &rfl" I 

J L 

You can turn off the abbrev processor with the control 
argument -no_abbrev (-nab). This control argument is the 
default. With it, you can override a command level abbrev for 
read__mail or send_mail that automatically turns on abbrev 
processing. For example, if you have the Rdm abbrev described 
above, you can enter read_mail and turn abbrev processing off 
like this: 



j Rdm -no_abbrev 
J 

Whenever conflicting control arguments appear on a command 
line-, the mail system uses only the last one to appear. Thus the 
above example turns off abbrev processing as you enter read_mail. 

Another way to turn off abbrevs within the mail subsystem is 
with the following request: 



I send__mail: ! abbrev -off 

J 
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When creating abbrevs within read__mail and send__mail, a 
useful request is the do request. This request is identical to 
the do command, except that it executes a request line within 
read_mail or send_mail, rather than a Multics command line. 
Similarly, the if and answer requests are like the if and answer 
commands, but they operate within the context of a mail 
subsystem. The do and if commands are documented in the Intro to 
Multics - Part II manual. All three of these requests are useful 
in the creation of abbrevs within the mail system. 



MORE ON CONTROL ARGUMENTS 

Fourteen read_mail and send__mail command control arguments 
have been described in earlier sections of this manual. There 
remain approximately fifty others, nearly half of which represent 
actions that the command performs by default. The purpose of 
such an extensive set of controls is to let you create your own 
desired read_mail and send__mail environments. To illustrate a 
few simple possibilities, here are several example command lines, 
using some control arguments that you know and some that have not 
been discussed: 



! I 
j rdm -print -quit J 

I rdm -list -no_header j 

J L 

The first read_mail command line above merely prints any messages 
that you have and quits, returning you directly to command level. 
The second example prints a list of all messages in the mailbox 
before giving the read_mail prompt; whenever you issue a print 
request, the message is printed with the brief form of header, 
just as if you had included the -no_header print request control 
argument each time. 



j sdm Moch.ProjCat -acknowledge -save outgoing j 
I sdm Moch.ProjCat -fm Willow. ProjCat -cmt "Pil Willow" -to | 
J L 

In the first send^mail example, the message you create is 
acknowledged automatically when the recipient prints it, and a 
copy of your message will be saved in your mailbox 
"outgoing. sv.mbx" . The second example places the comment Pil 
Willow after the User__id Willow. ProjCat in the From field of the 
message header; the -to control argument is added so that all 
addresses typed afterward will be included in the To field. 
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Control Arguments and start up.ec Segments 



Another method of setting up your own read_mail environment 
is to place a read_mail command line, such as the one used in the 
previous example, at the end of your start_up exec__com segment. 
In this case, when your start_up.ec has completed, you will be 
placed directly in read__mail. If you have no mail, you receive a 
notice to that effect and are returned to command level. If you 
do have mail, you receive a list of your messages and then a 
read__mail prompt. Here is an illustration: 



Multics MR8.0: Honeywell LISD Phoenix, System M 

Load = 102 out of 125.0 units: users = 109 08/01/80 ... 

login Willow ProjCat 

Password: 



<login information> 
You have four messages. 

Msg# Lines Date Time From Subject: 

1* (4) 08/01/80 09:14 Moch. ProjCat picnic 

2 (1) 08/01/80 10:26 Brie.ProjDog and you? 

3 (2) 08/01/80 13:02 Merce .Pro jDog your talk 

4 (27) 08/01/80 16:47 Edgar .Pro jDog comments y<MORE> 



read mail: 



You can use your start_up.ec for other mail system functions, 
I also. For instance, you could have your messages printed offline 
for you automatically each time you log in, by employing the 
-request ("rq) command control argument, and an 
I enter_output_request command line. This control argument enables 
you to give one or more read__mail requests after it {the list of 
requests must be quoted if there are any blanks); the specified 
requests are performed automatically, without entering the 
read__mail request loop. Place these two lines in your 
start__up.ec: 



i rdm -rq "write all my; delete all; quit" j 
I eor my. mail | 

J L 

You are not placed in read_mail as you would have been in the 
previous example, because with this line you included the quit 
request as part of the read_mail command line. 
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ESCAPING TO COMMAND LEVEL 



There are several ways to use the Multics command environment 
while you remain inside the mail system. This ability can be 
handy for a variety of purposes. 



The Escape 

To issue a Multics command within read_mail or send__mail, 
simply type two periods directly after the prompt, followed by 
the command line: 

read_mail: ! .. who OR send_mail: ! .. who 

When the command has finished, you receive another read_mail or 
send__mail prompt. 

You can use this escape to check on which mail segments and 
mailboxes you have in your directory (.. list) and to attend to 
other Multics activities when they occur to you 
(.. sm Brie.ProjDog Let's eat.) without having to end your mail 
session prematurely. 

You are free to use any command language conventions and 
facilities in the same way you do outside the mail system. 
Active functions (discussed in the New Users' Intro - Part II) 
are especially useful in providing the command language with 
extra flexibility. Here are two examples: 



read_mail: sm [ last_message_sender ] Sure, I'm hungry too | 
send_mail: .. eor [home__dir ]>canine .mail j \ 



Standard quoting and semicolon conventions also apply when using 
the .. escape. 
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Re-entering the Mail System 



A very convenient feature of the escape is that from 

either reacl_mail or send_mail you can re-enter read_mail to 
examine another mailbox, using the methods illustrated in 
"Examining Other Mailboxes" of Section 6. For example, you can 
check the contents of your logbox while in your default mailbox: 



read__mail: ! .. rdm -log -list 
There is one message in your logbox. 

Msg# Lines Date Time From Subject 
1 (4) 08/01/80 09:14 Moch.ProjCat picnic 

read_mail (2): 



Notice that this read_mail prompt looks somewhat different from 
the usual one. The number in parentheses indicates the recursion 
level — how many times you have entered read_mail within one 
mail session. 

If you can't remember which mailbox you're in, use the , 
request. This request prints one line of information about that 
mailbox, including the pathname, as well as the state of the 
messages contained in the mailbox: 

read_mail 8.3 (level 2): Message #1 of 1. 
> udd> P r o j Ca t >Moc h>Moc h . mbx 

If the mailbox is one of your default mailboxes, you receive a 
note rather than an explicit pathname: 

read__mail 8.3 (level 2): Message #1 of 1. 
Reading your logbox. 

You can also re-enter send_mail from either read_mail or 

send_mail, to send a message to one person while creating another 

message for someone else. The resulting send_mail prompts look 
like the read__mail prompt shown above: 

send__mail (2): 

The . request is also available here: 

send__mail 6.0 3 lines (unprocessed); Subject: your talk 

In send_mail the . request gives you information about the 
message you are creating. 
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ACTIVE REQUESTS 



Just as active functions increase flexibility within Multics 
command lines, active requests allow mail system request lines 
more flexibility. The four most useful ones are: 



Active requests are hereafter referred to by their short names in 
this section, to distinguish them from requests. 

The sj active request returns the current subject of the 
message you are working on. Wherever you type [sj] on a request 
line, the mail system replaces that with the current contents of 
the Subject field. Two ways of using this active request are: 

send_mail: I subject [sj] and lunch 

to add the words " and lunch" to the existing Subject field (this 
example also employs the subject request), and: 

send_mail: ! append [sj] 

which places the created message in a mail segment with the 
Subject field as its name. (This last is best done with a 
one-word subject — otherwise you will have embedded blanks in 
the name, which would result in an invalid pathname.) 

With the e active request, you can incorporate Multics active 
functions into mail system request lines, thereby increasing your 
options still more! The way to do this is to enclose the e 
active request, a space, and then an active function inside 
brackets. Below are a few simple examples: 

read_mail: i save 3 [e home__dir ]>f eline 

for saving mail when you are not working in your home directory; 

send__mail: ! to [e last__message_sender ] 

for sending mail to the user who last sent you an interactive 
message; 

send_mail: ! send [e contents people_at_work] 

to send mail to each person whose User_id is included in the 
segment "people_at_work" ; 



in send mail: 



in read mail: 



subject (sj) 
execute (e) 



mailbox (mbx) 
execute (e) 
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read_mail: ! append all [e date] 

to place all your messages in a mail segment with today's date as 
its name. 

The e active request and the mbx active request, which 
returns the pathname of the mailbox you are currently reading, 
are most commonly used with the execute request, described below. 



MORE REQUESTS 



The execute Request 

The execute request (not to be confused with the e (execute) 
active request!) performs a function very similar to that of the 

escape, because it also passes the following line to command 
level to be acted on. Before the command line reaches command 
level, however, it passes through the request processor. This 
means that all special request line syntax, such as the active 
request brackets described above, gets processed first. The 
results are placed in the command line, and then the line gets 
processed as a command line. To illustrate with the mbx active 
request, which returns the pathname of the mailbox you are 
currently reading, you can type: 

read__mail: execute mbx_list__acl [mbx] 

to see the access control list for that mailbox (for descriptions 
of all mailbox access commands see Appendix B). After this 
request line goes through the request processor, it looks like 
the command line shown below, although you do not see this 
intermediate step: 

mbx__list_acl >udd>ProjCat>Willow>Willow, sv.mbx 

and it is processed just like any other command line. 

Remember that the mbx active request is not a Multics active 
function. If you forget this, and try typing: 

read_mail: ! .. mbx_list_acl [mbx] 

you would receive the error message "Segment mbx not found". 

You may also use the e active request within an execute 
request line, of course. For example, if you have created a mail 
segment like the one in the last example in the previous section, 
you could get a printout of it in one of two ways, while in 
read_mail : 

read_mail: ! .. eor [date]. mail 
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or else: 

read_mail: ! execute eor [e date]. mail 



The apply Request 

If you prefer another Multics 
use the apply (ap) request to 
send_mail. Once in the send_mail 
the name of the editor you wish 
Emacs (on a video terminal), type: 



text editor to qedx, you may 
edit your message while in | 
request loop, type apply and 
to use. For example, to use 



send__mail: ! apply emacs 



The screen will be cleared and replaced by the message within an 
Emacs buffer. When you are finished with your editing, you must 
write out the changes you have made, by typing '^X^S. Then type 
^X^C as usual, and the familiar send_mail prompt will appear. 
(See the New User's Intro - Part I or the Emacs Text Editor 
Users' Guide (Order No. CH27) for information on Emacs.) 

The apply request operates by appending the pathname of the 

temporary segment (created to hold your message before you send 
it) to the command line you provided - in the above case it was a 
command that invokes a text editor. Therefore the apply request 
also allows you to utilize your own exec__coms, and any compatible 
subsystems that may have been created at your Multics 
installation. 



The exec com Request 

Within read__mail and send_mail, you can use the exec_com 
(ec) request to invoke an ec. The ec request works like the 
exec_com command documented in New Users' Intro - Part II, except 
that it makes use of read_mail or send^mail requests, rather than 
command level command sequences. 

A read_mail ec segment must have the suffix "rdmec", and a 
send__mail ec must have the suffix "sdmec". An ec ending with any 
other suffix will not work in the mail system. These suffixes 
are used to avoid confusion with Multics command level ecs. 

When you invoke an ec request within the mail system, your 
working directory is automatically searched, and then the 
following directory: 



j >udd>Project_id>Person__id>Person_id.mlsys 

I 
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If the ec is not found in either of these directories, you will 
get an error message. 

User Willow. ProjCat named the following simple ec 
"mo.rdmec", and put it in the >udd>ProjCat>Willow>Willow.mlsys 
directory: 



£tCommand_line off 
Is -fm Moch. ProjCat 
&command_line on 
&guit 



In read_mail, user Willow types the ec request and gets an 
appropriate response: 



read_mail ec mo 

Msg# Lines Date Time From Subject: 

1* (4) 08/01/80 09:14 Moch:ProjCat picnic 

5 (8) 08/03/80 11:23 Moch:ProjCat my plans 

8 (14) 08/05/80 12:36 Moch:ProjCat meeting 
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APPENDIX A 
MAIL SYSTEM COMMANDS 
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print^mail (prm) print_mail (prm) 



print_mail (prm) 



The print_mail command prints all the messages in a mailbox, 
querying the user whether to delete each one. 



SYNTAX AS A COMMAND 



prm {mbx_specif ication) {-ca} 
ARGUMENTS 



mbx^spec i f icat ion 

specifies the mailbox to be printed. If not specified, the 
user's default mailbox (>udd>Project>Person>Person.mbx) is 
assumed. The mailbox must be specified in one of the 
following forms: 

-log 

specifies the user's logbox and is equivalent to: 

-mailbox >udd>Pro ject__id>Person_id>Person_id. sv .mbx 

-mailbox PATH 
-mbx PATH 

specifies the pathname of a mailbox. The .mbx suffix is 
assumed if it is not present. 

-save PATH 
-sv PATH 

specifies the pathname of a savebox. The .sv.mbx suffix 
is assumed. 

-user Person_id.Pro ject_id 

specifies the given user's default mailbox. This control 
argument is equivalent to: 

-mailbox >udd>Project__id>Person__id>Person_id. sv.mbx 

STR 

is any non-control argument. First it is interpreted as 
-mailbox STR; if no mailbox is found, it is interpreted 
as -save STR; if no savebox is found, it is interpreted 
as -user STR. 
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print_mail (prm) 



print__mail (prm) 



CONTROL ARGUMENTS 



-acknowledge 
-ack 

acknowledges messages that request acknowledgement. This is 
the default. 

-brief 
-bf 

shortens the print_mail notice of the number of messages in 
the mailbox. 

-header 
-he 

prints the complete message headers with the message text. 
This is the default. 

- interact ive_messages 
-im 

operates on interactive messages from send_message (when 
accept_messages -hold is in effect) as well as mail messages 
from send__mail. This is the default. 

-list 
-Is 

prints a summary of the messages in the mailbox before 
printing the first message. 

-long 
-Ig 

prints the long form of the print_mail message count notice. 
This is the default. 

-no_ac knowledge 
-nack 

does not acknowledge any messages. 

-no_header 
-nhe 

prints a shortened form of the message header for each 
message. 

-no^interact ive__messages , 
-nim 

operates on send_mail messages only, not on interactive 
messages sent by send__message . 
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print__mail (prm) 



print_mail (prm) 



-no__list 
-nls 

does not prints a summary of the messages. This is the 
default. 

-no_reverse 
-nrv 

prints the messages in ascending numeric order. This is the 
default. 

-own 

prints only those messages that the user has sent to the 
mailbox. 

-reverse 
-rv 

prints messages in reverse order. 



QUERY RESPONSES 

a list of the acceptable responses is printed, and the 
question is asked again. 

yes 

y 

the message is deleted and the next one is printed. 

no 
n 

the message is not deleted and the next one is printed. 

reprint 
print 
pr 
P 

the message just printed is printed again, and the question 
is asked again. 

quit 

q 

the user is returned to command level after the specified 
messages are deleted. 

abort 

the user is returned to command level and no messages are 
deleted. 
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print_inail (prm) 



print_mail (prm) 



NOTES 



A default mailbox is created automatically the first time a 
user issues pr internal 1, read__mail, accept_messages , or 
pr internes sages. The default mailbox is: 

>user_dir__dir>Project_id>Person__id>Person_id.mbx 

To create additional mailboxes, and for more information on 
mailbox access, see Appendix B, "Mailbox Commands". 

The user can interrupt the printing of a message by pressing 
the BREAK or INTERRUPT key, and then type the program_interrupt 
(pi) command to proceed directly to the "Delete the message?" 
query. In this way, he can delete or save the message without 
having to print the entire message text at his terminal. 
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read__inail (rdm) read_mail (rdm) 



read^mail (rdm) 

The read_mail conunand provides a facility for examining and 
manipulating messages sent by the send_mail and mail commands. 

SYNTAX AS A COMMAND 

rdm {mbx_specif ication} {-ca} 

ARGUMENTS 



mbx_specif ication 

specifies the mailbox to be examined. If not specified, the 
user's default mailbox (>udd>Project>Person>Person.mbx) is 
assumed. The mailbox must be specified in one of the 
following forms: 

-log 

specifies the user's logbox and is equivalent to: 

-mailbox >udd>Pro ject_id>Person_id>Person_id.sv,mbx 

-mailbox PATH 
-mbx PATH 

specifies the pathname of a mailbox. The .mbx suffix is 
assumed if it is not present. 

-save PATH 
-sv PATH 

specifies the pathname of a savebox. The .sv.mbx suffix 
is assumed. 

-user Person_id.Project_id 

specifies the given user's default mailbox. This control 
argument is equivalent to: 

-mailbox >udd>Project_id>Person_id>Person_id. sv.mbx 

STR 

is any non-control argument. First it is interpreted as 
-mailbox STR; if no mailbox is found, it is interpreted 
as -save STR; if no savebox is found, it is interpreted 
as -user STR. 
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read mail (rdm) 



read_mail (rdm) 



CONTROL ARGUMENTS 

-abbrev 
-ab 

enables abbreviation expansion of request lines. 

-acknowledge 
-ack 

acknowledges messages that request acknowledgement. This is 
the default. 

-brief 
-bf 

shortens or omits many of the informative notices printed by 
read_mail. 

-count 
-ct 

prints the total number of messages in the mailbox before 
entering the request loop. This is the default, 

-header 
-he 

causes the print (pr) request to print complete message 
headers. This is the default. 

- interact ive_messages 
-im 

operates on interactive messages from send_message (when 

accept_messages -hold is in effect) as well as send__mail 

messages. If this control argument is not given, interactive 
messages are ignored. 

-list 
-Is 

prints a summary of the messages in the mailbox before 
entering the request loop. 

-long 
-Ig 

prints the full text of read_mail informative notices. This 
is the default. 

-no_abbrev 
-nab 

does not enable abbreviation expansion of request lines. 
This is the default. 
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reacl__mail (rdm) 



read mail (rdm) 



-no_ac knowledge 
-nack 

does not acknowledge any messages. 
-no__count 

does not print the total number of messages in the mailbox 
before entering the request loop. 

-no_header 
-nhe 

causes the print (pr) request to print an abbreviated form of 
the message header. 

-no_interactive_messages 
-nim 

operates only on send_mail messages, not on interactive 
messages sent by send_message. This is the default. 

-no_list 
-nls 

does not print a summary of messages before entering the 
request loop. This is the default. 

-no_pr int 
-npr 

does not print messages before entering the request loop. 
This is the default. 

-no_prompt 

does not prompt for read_mail requests when inside the 
request loop. This control argument is equivalent to -prompt 
The default prompt is "read_mail (N) : " , where N is the 
recursion level if greater than one. 

- n o__r eque s t __1 oop 
-nrql 

does not enter the request loop if there are no messages in 
the mailbox. This is the default. 

-own 

operates only on the user's own messages instead of on all 
the messages. This control argument can be useful when 
examining another user's mailbox. 

-print 
-pr 

prints the messages in the m.ailbox before entering the 
request loop. 
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read mail (rdm) 



read_mail (rdm) 



-profile path 
-pf path 

specifies the pathname of the profile to use for abbreviation 
expansion. The profile must already exist. The suffix 
"profile" is added if necessary. This control argument 
implies -abbrev, 

-prompt STR 

changes the prompt for read__mail request lines to STR, If 
STR is the user is not prompted, STR can be an ioa_ 

control string. 

-quit 

exits after performing any operations specified by control 
arguments. The default is to enter the request loop. 

-request STR 
-rq STR 

provides an initial request line, specified by STR, to be 

executed by read_mail before entering the request loop. STR 
must be enclosed in quotation marks if it contains blanks. 
Thus, the command line: 

! read__mail -rq "print lastjquit" -brief 

prints the last message in the user's mailbox and returns to 
command level. 

-request__loop 
-rql 

enters the read_mail request loop even if there are no 
messages in the mailbox. 

-totals 
-tt 

prints the number of messages in the mailbox, and returns to 
command level. This control argument is incompatible with 
-list, -quit, -request, -request_loop, and -print. 

The -header and -no__header control arguments can be used to set 
default values for the print request. 
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read mail (rdm) 



read mail (rdm) 



The following control arguments can be used to set default values 
for the reply request: 



These control arguments are described with the reply request 
below, with the exception of -fill, -no__fill, and -1 ine_length N, 
which are described in the send_mail description. 



Many of the read_mail requests take the same arguments and 
control arguments, in the form of message specifiers (spec) and 
message selection control arguments (-selca). These message 
specifiers, and selection control arguments are completely 
described in the next few pages; they are simply listed in the 
subsequent read_mail request descriptions. 



Message Specifiers 

Most read^mail requests are capable of processing several 
messages in one invocation. The messages are identified by one 
or more message specifiers. 

selection contr Message specifiers normally refer only to the 
messages in a mailbox that have not been marked for deletion. 
Most read_mail requests accept the following control arguments, 
which modify the set of messages available for selection by the 
message specifiers: 

-include deleted 



includes all messages in the mailbox, whether or not they 
have been deleted, when interpreting the message 
specifiers to determine which messages to process. 

~only_deleted 
-odl 

includes only those messages that have been deleted. 



-fill, -fi 

-include_authors, -iat 
=include_original , -io 
-include__recipients, -ire 
-include_self , -is 
-indent N, -in N 



-line_length N, -11 N 
-no__fill, -nfi 
-no_include__authors, -niat 
-no_include__original , -nio 
-no_include_recipients , -nirc 
-no include self, -nis 



NOTES 



-idl 
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read mail (rdm) read mail (rdm) 



-only_non_deleted 
-ondl 

includes only those messages that have not been deleted. 
This is the default. 

If a message specifier identifies a range of messages (see 
below), at least one message in that range must be of the 
appropriate type, as determined by the above control arguments. 

The simplest form of a message specifier is simply a message 
number, such as 3. Message numbers are assigned by read_mail 
when it first reads the mailbox. Even when messages are deleted, 
message numbers do not change during the invocation. The 
following keywords can be used to refer to an individual message 
without specifying its message number: 

first 
f 

identifies the first message of the appropriate type in 
the mailbox, (The first message (#1) is identified if 
-idl is given; the first deleted message is identified if 
-odl is given; and the first non-deleted message is given 
if -ondl or none of these control arguments is given.) 

last 
1 

identifies the last message of the appropriate type in 
the mailbox. 

next 
n 

identifies the next message of the appropriate type in 
the mailbox. 

previous 
P 

identifies the previous message of the appropriate type 
in the mailbox. 

current 

c 

. 

refers to the current message. The current message is 
initially the first message in the mailbox. Most 
requests set the current message to the last message 
processed by the request. For example, after executing 
the request: 
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I print 4 12 j 
J L 

the current message is message #12, 

Ranges of messages can be identified by two message numbers 
or keywords separated by a colon (:). For example, the following 
line: 



1 3: last I 
J L 

identifies all messages of the appropriate type from message #3 
through the last message of the appropriate type in the mailbox. 
The keyword "all" is accepted as shorthand for "f irst : last" ; it 
identifies all messages of the appropriate type in the mailbox. 

Message numbers can be added and subtracted using "+" and 
For example, if the current message is #20, the following 

line: 



i current-5:current+10 j 
J L 

identifies all messages of the appropriate type from message #15 
through #30. As this example demonstrates, arithmetic operations 
are performed after any message keywords are converted to 
absolute numbers. 

Qedx regular expressions can be used to select all messages 
of the appropriate type that contain a given string. The regular 
expression must be enclosed in slashes (/); for an explanation of 
the syntax of regular expressions, see the Qedx Text Editor's 
User Guide, Order No. CG40. If the regular expression contains 
spaces, horizontal tabs, quotes ("), parentheses, or brackets, 
the entire expression must be enclosed in quotes to avoid 
misinterpretation by the request line processor; any quotes 
within the regular expression must be doubled. For example. 



/saia, ""I tnmK/ 
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j said, "I think j 

J : L 

A regular expression can be preceeded by one of the keywords 
listed above to select the first, last, etc. message containing 
that string. Additionally, two or more regular expressions can 
be combined by connectors to express logical AND (&) and logical 
OR {|). For example, the following line: 



j last/artif icial/&/intelligence/ 
J 

specifies the last message of the appropriate type containing 
both of the strings "artificial" and "intelligence". 



Message Selection Control Arguments 

The list, print, pr int_header , delete, and retrieve requests 
accept several control argum.ents that supply further criteria for 
message selection. If no message specifiers are given, all 
messages of the appropriate type in the mailbox are considered 
for selection. For example, the request line: 



j list 23:30 -from Ellery.Proj j 

J L 

lists all non-deleted messages in the mailbox from message #23 
through #30 that were sent by the user Ellery.Proj. 

Selection control arguments are divided into four classes — 
subject selection, time selection, author selection, and 
recipient selection. If several control arguments from one class 
are provided, a message must only satisfy one of the selections 
in that class to be considered by the request. If control 
arguments from more than one class are provided, a message must 
satisfy one of the selections in all of these classes provided to 
be considered by the request. For example, the request line: 
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j list -from Ellery.Proj -from Green.Proj -after 1/1/82 j 
J L 

lists all non-deleted messages in the mailbox that were: a) sent 
by either Ellery.Proj or Green. Proj, and b) sent any time from 
January 1982 to the present. A message sent by Ellery.Proj on 23 
December 1981 would not be listed by this request. 

Two control arguments allow the user to determine when to 
ignore the distinction between upper and lower case characters 
when examining header fields. All selection control arguments 
are affected by the following two control arguments. 

-case__sensitive 
-cs 

causes subject selections and qedx regular expression 
searches for author and recipient selections to make a 
distinction between upper and lower case characters. This is 
the default. 

-non_case_sensitive 
-ncs 

causes subject selections and qedx regular expression 
searches for author and recipient selections to ignore the 
distinction between upper and lower case characters. 

Thus, the following request line: 



i -sj book -non_case_sensit ive j 
J L 

matches a Subject field if it contains any of the strings "book", 
"BOOK", "Book", etc. 

Subject selection control arguments may use either qedx 
regular expressions or literal matches. The string value (STR) 
supplied to these control arguments is interpreted as a qedx 
regular expression if it is surrounded by slashes {/); otherwise, 
a literal occurrence of the string must appear in the header 
field. If the string contains any spaces, horizontal tabs, 
quotes, parentheses, or brackets, it must be enclosed in quotes 
to avoid misinterpretation by the request line processor, and any 
quotes in the string must be doubled. The following line selects 
messages whose Subject fields start with the string "read_mail". 
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I 

I ~sj /'^read_mail/ 
J 

-in_reply_to STR 
-in_reply_to /STR/ 
-irt STR 
-irt /STR/ 

selects any messages whose In-Reply-To field contains 
STR. 

-subject STR 
-subject /STR/ 
-sj STR 
-sj /STR/ 

selects any messages whose Subject field contains STR, 

Time selection control arguments apply to the date/time that 
the message was created, as indicated in the message's Date 
header field. In the following descriptions, DT, DTI, and DT2 
represent date/time strings. (For details of the acceptable 
date/time string formats, see the Programmer's Reference manual.) 
In the case of -between, -after, and -before, the date/times 
specified are truncated to an appropriate midnight. For example: 




I -between 9/1/82 9/30/82 j 
1_ L 

matches all messages created during the month of September 1982. 

-after DT 
-af DT 

selects any messages that were created on or after the 
date specified by DT. 

-before DT 
-be DT 

selects any messages that were created before the date 
specified by DT. 

-between DTI DT2 
-bt DTI DT2 

selects any messages that were created between the dates 
DTI and DT2 inclusively. 
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-date DT 
-dt DT 

selects any messages that were created on the date 
specified by DT. 

The following time selection control arguments do not 
truncate the date/times specified to an appropriate midnight. 
Therefore, they provide finer control on the messages selected by 
time: 

-after__time DT 
-aft DT 

selects any messages that were created after the 
date/time specified by DT. 

-before_time DT 
-bet DT 

selects any messages that were created before the 
date/time specified by DT. 

-between__t ime DTI DT2 
-btt DTI DT2 

selects any messages that were created between the 
date/times specified by DTI and DT2 inclusively. 

Author and recipient selection control arguments either match 
the individual addresses within the appropriate header field, or 
match the entire content of the header field as a single string 
using a qedx regular expression. (See the Programmer's Reference 
manual for a description of appropriate address syntaxes.) If 
the value supplied to these control arguments is surrounded by 
slashes, it is interpreted as a qedx regular expression to match 
against the entire content of the header field. Otherwise the 
value, which may consist of several tokens, is interpreted as an 
address that must exactly match one or more of the addresses in 
the field. 

If a qedx regular expression match is requested and the 
string contains any spaces, horizontal tabs, quotes, parentheses, 
or brackets, it must be enclosed in quotes to avoid 
misinterpretation by the request line processor. Further, any 
quotes in the string must be doubled. For example: 



-from /Green. *Proj/ 



matches any message 
"Green" and "Proj". 



whose From field contains the two strings 
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The following line matches any message with a primary recipient 
named "grb" on the foreign system "System-Q". 



-to grb -at System-Q 



-cc address 
-cc /STR/ 

selects any messages whose cc field either contains the 
specified address or matches the given qedx regular 
expression. 



-f orwarded_to address 
-f orwarded__to /STR/ 
-fwdt address 
-fwdt /STR/ 

selects any messages whose Redistributed-To field either 
contains the specified address or matches the given qedx 
regular expression, 

-from address 
-from /STR/ 
-fm address 
-fm /STR/ 

selects any messages whose From field either contains the 
specified address or matches the given qedx regular 
expression. 

-recipient address 
-recipient /STR/ 
-rep address 
-rep /STR/ 

selects any messages whose To, cc , or Redistributed-To 
fields either contain the specified address or match the 
given qedx regular expression. 

-reply__to address 
-reply_to /STR/ 
-rpt address 
-rpt /STR/ 

selects any messages whose Reply-To field either contains 
the specified address or matches the given qedx regular 
expression. 
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-to address 
-to /STR/ 

selects any messages whose To field either contains the 
specified address or matches the given regular 
expression. 



REQUESTS 

In the following read_mail requests descriptions, "spec" means 
"message__speci f ier" , "-selca" means "-selection_args" , and "-ca" 
means "-control_args" • 

prints a multi-columnar list of the read_mail requests. 



prints a line identifying the current version of read_mail, 
the current message number, the message count, the number of 
deleted messages, and the pathname of the mailbox being read 
as in: 



1 

j read mail 8.3 

1 

1 


1 

: Message #7 of 11, 3 deleted. | 
Reading your mailbox j 

1 


If abbreviation 
string "(abbrev)" 


expansion of request lines is enabled, the 
is included in parentheses: 


1 read mail 8.3 

1 
1 


1 

(abbrev): Message #2 of 7. | 
Reading your mailbox. | 

1 


If the recursion 
parentheses after 


level is greater than one, it is included in 
the (abbrev) string, if any: 


1 

1 read mail 8.3 

1 
1 


1 

(abbrev) (level 2): Message #2 of 5. j 

>udd>X>Y>22.sv.mbx | 

1 



. . STR 

passes a command line, specified by STR, directly to the 
standard command processor, without processing by the 
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read^mail request processor. The string must be the 

first two characters of this request line. 

abbrev {-ca} 
ab {-ca} 

controls abbreviation processing within read_mail. If 
invoked with no arguments, this request enables abbrev 
processing within read__mail using the profile that was last 
used in this read_mail invocation. If abbrev processing was 
not previously enabled, the profile in use at Multics command 
level is used; this profile is normally 

[home dir ]>Person_id.prof ile. (See the Commands manual for a 
description of abbreviation processing.) 

The read__mail subsystem also has command line control 
arguments (-abbrev, -no__abbrev, and -profile) that specify 
the initial state of abbreviation processing within 
read_mail. For instance, a Multics abbreviation could be 
defined to invoke the read__mail subsystem with a default 
profile as follows: 



j .ab rdm do "rdm -abbrev -profile [hd]>mail_system &rfl" j 
J L 

Control arguments may be chosen from the following: 
-off 

specifies that abbreviations are not to be expanded. 

-on 

specifies that abbreviations are expanded. This is the 
default. 

-profile path 

specifies that the segment named by path is to be used as 
the profile segment. The suffix ".profile" is added to 
path if it is not present. The segment named by path 
must exist prior to the use of this control argument. 

[abbrev] 

returns "true" if abbreviation expansion of request lines is 
currently enabled within read_mail, and "false" otherwise. 

all {-ca} 

prints the message numbers for all messages of the specified 
type. Control arguments for specifying the type of message 
numbrrs may be one of the following: 
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-include deleted 
-idl 

prints the numbers of all messages in the mailbox, 
including deleted ones. 

-rto_reverse 
-nrv 

prints the message numbers in normal order (smaller 
numbers first). This is the default. 

-only_deleted 
-odl 

prints only the numbers of deleted messages. 

-only__non_deleted 
-ondl 

prints only the numbers of messages that have not been 
deleted. This is the default. 

-reverse 
rv 

prints the message numbers in reverse order, 
[all {-ca}] 

returns the message numbers, separated by spaces, of all 
messages of the given type. If there are no messages of that 
type, it returns a null string. This active request takes 
the same control arguments as the all request. 

answer STR {-ca} request_line 

provides preset answers to questions asked by another 
request. It establishes an on unit for the condition 
command_question, and then executes the designated request 
line. If any request in the request line calls the 
command_query_ subroutine (described in the Subroutines 
manual) to ask a question, the on unit is invoked to supply 
the answer. The on unit is reverted when the answer request 
returns to read_mail request level. See the Reference manual 
for a discussion of the command__question condition. If a 
question is asked that requires a yes or no answer, and the 
preset answer is neither "yes" nor "no", the on unit is not 
invoked. 

The last answer specified is issued as many times as 
necessary, unless followed by the -times N control argument. 

The -match and ^exclude control arguments are applied in the 
order specified. Each -match causes a given question to be 
answered if it matches STR; each -exclude causes it to be 
passed on if it matches STR. A question that has been 
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excluded by the -exclude control argument is reconsidered if 
it matches a -match later in the request line. 

The arguments are: 

STR 

is the desired answer to any question. If the answer is 
more than one word, it must be enclosed in quotes. If 
STR is -query, the question is passed on to the user. 
The -query control argument is the only one that can be 
used in place of STR, 

request_line 

is any read__mail request line. It can contain any number 
of separate arguments (i.e., have spaces within it) and 
need not be enclosed in quotes. 

Control arguments may be chosen from the following: 

-brief 
-bf 

suppresses printing (on the user's terminal) of both the 
question and the answer. 

-call STR 

evaluates the active string STR to obtain the next answer 
in a sequence. The active string is constructed from 
read__mail active requests and Multics active strings 
(using read_mail's "execute" active request). The 
outermost level of brackets must be omitted and the 
entire string must be enclosed in quotes if it contains 
request processor special characters. The return value 
"true" is translated to "yes", and "false" to "no". All 
other return values are passed as is. 

-exclude STR 
-ex STR 

passes on, to the user or other handler, questions whose 
text matches STR. If STR is surrounded by slashes (/), 
it is intei-preted as a qedx regular expression. 
Otherwise, answer tests whether STR is literally 
contained in the text of the question. Multiple 
occurrences of -exclude are allowed; they apply to the 
entire request line. 

-match STR 

answers only questions whose text matches STR, If STR is 
surrounded by slashes (/), it is interpreted as a qedx 
regular expression. Otherwise, answer tests whether STR 
is literally contained in the text of the question. 
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Multiple occurrences of -match are allowed; they apply to 
the entire request line. 

-query 

skips the next answer in a sequence, passing the question 
on to the user. The answer is read from the user_i/o I/O 
switch. 

-then STR 

supplies the next answer in a sequence, 
-times N 

gives the previous answer (STR, -then STR, or -query) N 
times only (where N is an integer). 

append {spec} path {-ca} 

app {spec} path {-ca} 

appends the specified messages (with headers) to the ASCII 
segment specified by path. The suffix .mail is added to path 
if it is not present. If the specified segment does not 
already exist, the user is asked whether to create it. This 
request causes the specified messages to be acknowledged, if 
requested by the senders (see send_mail -acknowledge). If 
required, it adds Date and From fields to the ASCII 
representations of the messages it places into the segment. 
Control arguments are: 

-delete 
-dl 

deletes the messages after appending them, if all the 
append operations were successful. 

- i nc lude_deleted 
-idl 

writes all specified messages, including deleted ones. 

-no_delete 
-ndl 

does not delete the messages after appending them. This 
is. the default . 

-no__reverse 
-nrv 

writes the messages in ascending numeric order. This is 
the default. 

-odl 

writes only deleted messages. 
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-only__non__deieted 
-ondl 

writes only those messages that have not been deleted. 
This is the default. 

-reverse 
-rev 

appends the messages in reverse order. 

apply {spec} {-ca} STR 

ap {spec} {-ca} STR 

places the text of the selected message(s) into a temporary 
segment in the process directory, then concatenates the 
command line specified by STR with intervening spaces and 
appends the pathname of the temporary segment. This command 
line is passed to the Multics command processor. The command 
line may not modify the contents of the temporary segment. 
Each message is processed individually. For example, the 
following read_mail request line: 



issues a separate output request for each message containing 
the string "Gomez". 

The supplied command line need not be enclosed in quotes. 
However, if (), []f or " are in the command line to be 
processed by the Multics command processor, they should be 
enclosed in quotes to prevent processing by read_mail's 
request processor. Control arguments are: 



deletes the .uessages after processing them, if all 
messages are successfully processed. 



specifies that the header of each message is to be 
included in the temporary segment. This is the default. 

-include__deleted 
-idl 

processes all specified messages, including deleted ones. 



spply /Gomez/ "do 



copy Scl eor &1 -dl""" 



-delete 
-dl 



-header 
-he 
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-no d«l«te 

-ndT 

does not delete the messages after processing them. This 
is the default. 

-no_header 
-nhe 

specifies that the header of each message is not to be 
included in the temporary segment. 

-no_reverse 
-nrv 

processes the messages in ascending numeric order. This 
is the default. 

-nontext 

specifies that the text of each message is not to be 
included in the temporary segment. 

-only_deleted 
-odl 

processes only deleted messages. 

-only_non_deleted 
-ondl 

processes only those messages that have not been deleted. 
This is the default. 

-reverse 
-rev 

processes the messages in reverse order, 
-text 

specifies that the text of each message is included in 
the temporary segment. 

copy {spec} path {-ca} 

cp {spec} path {-ca} 

copies the specified messages into the mailbox designated by 
path. The mailbox must already exist. The .mbx suffix is 
added to path if it is not present. The messages are copied 
exactly as they appear in the original mailbox; no header 
fields are added, interactive messages are not converted to 
normal messages, etc. This request does not send 
acknowledgements for any of the messages that it processes. 
If the original message requests an acknowledgement, the 
copied message also requests an acknowledgement to the sender 
of the original message. Control arguments are the same as 
for the append request. 
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current 
c 

prints the number of the current message, 
[current] 

returns the number of the current message, or 0 if there is 
no current message. 

delete {spec} {-selca} {-ca} 

dl {spec} {-selca} {-ca} 

d {spec} {-selca} {-ca} 

deletes the specified messages. If no messages are 
specified, the current one is deleted. Deleted messages can 
be retrieved before exiting read___mail by using the retrieve 
(rt) request. The user is queried for permission if he 
attempts to delete a message that has not been the subject of 
one of the following requests: apply, copy, forward, list, 
log, preface, print, pr int_header , reply, save, write. Thus 
the user is protected from accidentally deleting 
newly-arrived messages without having first examined them. 

Control arguments for the delete request may be one of the 
following: 

-force 
-fc 

deletes unprocessed messages without querying, and 
ignores messages that can not be deleted due to 
insufficient access. 

-no__f orce 
-nfc 

queries the user for permission to delete any unprocessed 
messages. No message is deleted if either the user 
answers "no" to a query, or the user lacks sufficient 
access to delete one or more of the specified messages. 

do STR {args} 
or 

do {-ca} 

expands a request line specified by STR by substituting the 
supplied arguments into the line before execution. Arguments 
are character string arguments that replace parameters in the 
request line. 
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The following control arguments set the mode of operation of 
the do request: 

-absentee 

an any_other handler is established that catches all 
conditions and aborts execution of the request line 
without aborting the process. 

-brief 
-bf 

the expanded request line is not printed before 
execution. This is the default. 

-go 

the expanded request line is passed on for execution. 
This is the default. 

-interactive 

the any_other handler is not established. This is the 
default . 

-long 
-Ig 

the expanded request line is printed before execution, 
-nogo 

the expanded request line is not passed on for execution. 

Any sequence beginning with & in the request line is expanded 
by the do request using the arguments given on the request 
line. Following is the list of parameters: 

Scl 

is replaced by argi . I must be a digit from 1 to 9. 

&(I) 

is also replaced by argI . I can be any value, however. 

Scql 

is replaced by argI with any quotes in argI doubled. I 
must be a digit from 1 to 9. 

&q{I) 

is also replaced by argI with any quotes doubled. I can 
be any value. 

&ri 

is replaced by all the arguments starting with argI . 
Each argument is placed in quotes with contained quotes 
doubled. I must be a digit from 1 to 9. 
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&r(I) 

is also replaced by a requoted argi . I can be any value. 

ficfl 

is replaced by all the arguments starting with argI . I 
must be a digit from 1 to 9. 

&f (I) 

is also replaced by all the arguments starting with argl. 
I can be any value. 

&qf I 

is replaced by all the arguments starting with argl with 
any quotes doubled. I must be a digit from 1 to 9. 

&qf (I) 

is also replaced by all the arguments starting with argl 
with quotes doubled. I can be any value. 

&rf (I ) 

is also replaced by all the arguments starting with argl, 
requoted. I can be any value. 

is replaced by an ampersand. 

&! 

is replaced by a 15 character unique string. The string 
used is the same everywhere &! appears in the request 
1 ine . 

&n 

is replaced by the actual number of arguments supplied. 

&f &n 

is replaced by the last argument supplied, 
[do STR {args}] 

returns a request line specified by STR with argument 
substitution. 

exec__com path {args} 
ec path {args} 

executes a program written in the exec_com language, where 
path is the pathname of an exec__com program. The suffix 
"rdmec" is added to the pathname if necessary. This program 
is used to pass request lines to read_mail and to pass input 
lines to requests that read input. Currently, any errors 
detected during an ec execution within read__mail will abort 
the .rquest line in which the ec request was invoked. The 
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arguments are optional arguments to the exec__com program and 
are substituted for parameter references in the program such 
as £cl. 

If the pathname does not contain a or">" character ^ 

read_mail searches for the exec_com program using the 
mail__system search list. The default content of this search 
list is: 



j -working_dir j 
I >udd>[user project ]>[user name]>[user name].mlsys j 

J ^ L 

When evaluating a read_mail exec_com program, subsystem 
active requests are used rather than Multics active functions 
when evaluating the &[...] construct and the active string in 
an Self statement. The read_mail execute active request may 
be used to evaluate Multics active strings within the 
exec_com. 

[exec_com path {args}] 

[ec path {args}] 

executes a program written in the exec_com language that 
specifies a return value of the exec_com request by use of 
the Ecreturn statement. The arguments are the same as for the 
exec_com request. 

execute STR 
e STR 

executes the supplied line as a Multics command line, where 
STR is the Multics command line to be executed or the Multics 
active string to be evaluated. It need not be enclosed in 
quotes . 

The recommended method to execute a Multics command line from 
within read_mail is the escape sequence. The execute 

request is intended as a means of passing information from 
read_mail to the Multics command processor. 

All (), [], and "'s in the given line are processed by the 
read_mail request processor, not the Multics command 
processor. Thus, the values of subsystem active requests may 
be passed to Multics commands when using the execute request. 
For example, the following request line lists the ACL of the 

uiolxuuA i^cxiiij i. eau Jw>y Liic k«ui.rctii, J. 11 V v^uo u X vyii i. cau mo x x • 
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e mbla [mailbox] 



[execute STR] 
[e STR] 

evaluates a Multics active string from within read_mail. For 
example, the following read mail request line: 



j write all [e strip_entry [mailbox]] j 
J L 

writes the ASCII representation of all messages in the 

mailbox into a segment in the working directory whose entry 
name is the same as that of the mailbox, with the "mbx" 
suffix changed to "mail". 

first {-ca] 
f {~ca} 

prints the number of the first message of the specified type. 
The control argument may be one of the following: 

-include__deleted 
-idl 

prints the number "1" (i.e., the number of the first 
message, whether or not it has been deleted.) 

-only_deleted 
-odl 

prints the message number of the first deleted message. 

-only_non_deleted 
-ondl 

prints the message number of the first non-deleted 
message. This is the default. 

[first {-ca}] 
[f {-ca}] 

returns the number of the first message of the specified 

type. If there are no messages of the specified type, it 

returns the value zero. This active request takes the same 

control arguments as the first request. 
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forward {spec} addresses {-ca} 
fwd {spec} addresses {-ca} 
for {spec} addresses {-ca} 

forwards the specified message to the addresses given. 

Control arguments to the forward request are the same as 

those for the append request. 

Forwarding addresses may be given in any of the forms 
described under "Addresses" in the send_mail command 
description (later in this appendix). 

This request adds three fields to the message header: 
Redistr ibuted-Date , Redistributed-By , and Redistr ibuted-To . 
It adds the Date and From fields to the original message if 
necessary before forwarding. The request also causes the 
message to be acknowledged, if requested by the original 
sender (see send__mail -acknowledge). 

To forward a set of messages that can not be identified by a 
single message specifier, request line iteration and the list 
active request may be used to avoid retyping the recipients. 
For example: 



j forward ([list 13 9 last-4 : last ] ) Fry. ABC Lee.Proj -dl j 
J L 

help {STR} {-ca} 

prints information about various read_mail topics, including 
detailed descriptions of read__mail requests. If specified, 
STR is the name of a read_mail request or one of the other 
available topics. If STR is not specified, the help request 
lists the requests that provide information about read__mail. 

The help request accepts most of the control arguments 
accepted by the Multics help command. Type ".. help help" 
for a complete description of the help request. Following is 
a description of some of the more useful control arguments 
for the help request: 

-brief 
-bf 

prints only a summary of a request or active request, 
including the Syntax section, list of arguments, control 
arguments, etc. 
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-search STRs 
-srh STRs 

begins printing with the paragraph containing all the 
strings STRs. By default, printing starts at the 
beginning of the information. 

-section STRs 
-sen STRs 

begins printing at the section whose title contains all 
the strings STRs. By default, printing starts at the 
beginning of the information. 



-title 

prints section titles and 
if the user wants to 
information. 



section line counts; then asks 
see the first paragraph of 



The most useful responses to questions asked by the help 
request are: 

prints the list of responses allowed to help queries. 



prints "help" to identify the current interactive 
environment . 

.. command_line 

treats the remainder of the response as a Multics command 
line. 

no 
n 

stops printing information for this topic and proceeds to 
the next topic, if any, 

quit 

q 

stops printing information for this topic and returns to 
the subsystem's request level. 

rest {-sen} 
r {-sen} 

prints remaining information for this topic without 
intervening questions. If -section or -sen is given, 
help prints only the rest of the current section without 
questions and then asks if the user wants to see the next 
section. 
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search {STRs} {-top} 

srh {STRs} {-top} 

skips to the next paragraph containing all the strings 
STRs. If -top or -t is given, searching starts at the 
top of the information. If STRs are omitted, help uses 
the STRs from the previous search response or the -search 
control argument. 

section {STRs} {-top} 

sen {STRs} {-top} 

skips to the next section whose title contains all the 
strings STRs. If -top or -t is given, title searching 
starts at the top of the information. If STRs are 
omitted, help uses the STRs from the previous section 
response or the -section control argument. 

skip {-sen} {-seen} 

s {-sen} {-seen} 

skips to the next paragraph. If -section or -sen is 
given, help skips all paragraphs of the current section. 
If -seen is given, help skips to the next paragraph that 
the user has not seen. Only one control argument is 
allowed in each skip response. 

title {-top} 

lists titles and line counts of the sections that follow; 
if -top or -t is given, help lists all section titles. 
The previous question is repeated after titles are 
printed. 



yes 

y 

prints the next paragraph of information on this topic. 

if [EXPR] -then LINEl {-else LINE2} 

conditionally executes one of two request lines depending on 
the value of an active string. The arguments are: 

EXPR 

is the active string that must evaluate to either "true" 
or "false". The active string is constructed from 
read_mail active requests and Multics active strings 
(using read^mail's execute active request). 

LINEl 

is the read_mail request line to execute if EXPR 
evaluates to "true". If the request line contains any 
request processor characters, it must be enclosed in 
quotes . 
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LINE2 

is the read_mail request line to execute if EXPR 
evaluates to "false". If omitted and EXPR is "false", no 
additional request line is executed. If the request line 
contains any request processor characters, it must be 
enclosed in quotes. 

[if [EXPR] -then STRl {-else STR2}] 

returns one of two character strings to the read_mail request 
processor, depending on the value of an active string. The 
arguments are: 

EXPR 

is the active string that must evaluate to either "true" 
or "false". The active string is constructed from 
read_mail active requests and Multics active strings 
(using read_mail's execute active request). 

STRl 

is returned as the value of the if active request if the 
EXPR evaluates to "true". 



STR2 

is returned as the value of the if active request if the 
EXPR evaluates to "false". If omitted and the EXPR is 
"false", a null string is returned. 

last {-ca} 
1 {-ca} 

prints the number of the last message of the specified type. 
The control argument may be one of the following: 

-include_deleted 
-idl 

prints the number of the last message, whether or not it 
has been deleted. 

-only_deleted 
-odl 

prints the number of the last deleted message. 

-only_non_deleted 
ondl 

prints the message number of the last non-deleted 
message. This is the default. 

[last {-ca}] 
[1 {-ca} 

returns the number of the last message of the specified type. 
If there is no message of the specified type, it returns the 
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value zero. This active request takes the same control 
arguments as the last request. 

list {spec} {-selca} {-ca} 

Is {spec} {-selca} {-ca} 

prints a summary line for each of the specified messages, or 
for all undeleted messages if no specifiers are given. 
Control arguments may be chosen from the following: 

-delete 
-dl 

deletes the messages after listing them. 

-header 
-he 

prints a header line before the list of messages. This 
is the default. 

-include_deleted 
-idl 

prints the list of messages, including deleted ones. 

-line_length N 
-11 N 

prints the list of messages, using the supplied line 
length N to determine where and if to truncate the 
message subject. (The default length is the terminal's 
line length.) 

-no_delete 
-ndl 

does not delete the messages after listing them. This is 
the default. 

-no_header 
-nhe 

omits the header line preceding the list of messages. 

-no_line_length 
-nil 

does not truncate the message subject unless the subject 
is more than one line long, 

-no_reverse 
-nrv 

lists the messages in ascending numeric order. This is 
the default. 
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-only_deleted 
-odl 

lists only deleted messages. 

-only_non_deleted 
-ondl 

lists only non-deleted messages. This is the default. 

-reverse 
-rev 

prints the list of messages in reverse order. 

The current message is marked (in the listing) by a to 
the right of the message number. If -idl or -odl is 
specified, deleted messages are marked by an " I " to the 
right of the message number. 

One or two lines are printed for each message. The format of 
the first line is: 



j N (L) MM/DD/YY HH:MM AUTHOR SUBJECT j 
-L L 

where N is the message number and L is the number of lines in 
the body of the message (excluding the header). MM/DD/YY 
HH:MM specifies the date/time when the message was originally 
transmitted. AUTHOR specifies the original author(s) of the 
message, and is normally as much of the From field of the 
message as will fit in the provided space. SUBJECT is as 
much of the Subject field, if present, as will fit on the 
line. If the message is an interactive message, SUBJECT is 
as much of the actual text of the message as will fit on the 
line. 

If the message has been forwarded, a second line is included 
in the listing. This line has the format: 



I (*) Forwarded (Nth time) at MM/DD/YY HH:MM by STR | 
J L 

where N indicates the number of times that this message has 
been forwarded. (N is omitted if the message has only been 
forwarded once.) MM/DD/YY HH:MM specifies the date/time that 
the message was last forwarded, and is derived from the most 
recent Redistr ibuted-Date field. STR specifies the person 
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who last forwarded the message, and is the contents of the 
most recent Redistr ibuted-By field in the message. 

[list {spec} {-selca} {-ca}] 

[Is {spec} {-selca} {-ca}] 

returns a list of the numbers of the specified messages 
separated by spaces. This active request takes the same 
selection arguments and control arguments as the list 
request. 

list_help {topics} 
Ih {topics} 

displays the name of all read_mail information segments on 
given topics. If no topics are given, all read_mail 
information segments are listed. 

When matching topics with info segment names, an info segment 
name is considered to match a topic only if that topic is at 
the beginning or end of a word within the segment name. 
Words in info segment names are bounded by the beginning and 
end of the segment name and by the characters period (.), 
hyphen (-), underscore (_) , and dollar sign ($). The ".info" 
suffix is not considered when matching topics. 

list_requests {STR} {-ca} 
Ir {STR} {-ca} 

prints a brief description of selected read_mail requests, 
where STR specifies the request (s) to be described. Any 
request with a name containing one of these strings is listed 
unless -exact is used, in which case the request name must 
exactly match one of these strings. When matching STRs with 
request names, a request name is considered to match a STR 
only if that STR is at the beginning or end of a word within 
the request name. Words in request names are bounded by the 
beginning and end of the request name and by the characters 
period (.), hyphen (-), underscore (_) , and dollar sign ($). 

Control arguments are: 

-all 
-a 

includes undocumented and unimplemented requests in the 
list of requests eligible for matching the STR arguments. 

-exact 

lists only those requests one of whose names exactly 
match one of the STR arguments. 
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log {spec} {-ca} 

saves the specified messages in the user's logbox. The 
user's logbox has the pathname 

>udd>Project_id>Person_id>Person_id. sv.mbx. It is created 
automatically if it does not already exist, and the user is 
informed of its creation. Date and From header fields are 
added as required to logged messages. Any messages requiring 
acknowledgement are acknowledged unless -no__acknowledge is 
specified on the read_mail command line. Control arguments 
for this request are the same as for the append request. 

mailbox 
mbx 

prints the absolute pathname of the mailbox currently being 
read. 



[mailbox] 
[mbx] 

returns the absolute pathname of the mailbox currently being 
read. 

next {-ca} 

prints the number of the next message of the specified type. 
The control argument may be one of the following: 

-include_deleted 
-idl 

prints the number of the next message in the mailbox, 
whether or not it has been deleted. 

-only_deleted 
-odl 

prints the number of the next deleted message. 

-only_non_deleted 
-ondl 

prints the number of the next non-deleted message. This 
is the default. 

[next {-ca}] 

returns the number of the next message number of the 
specified type. If there are no messages of the specified 
type, the value zero is returned. This active request takes 
the same control arguments as the next request. 

preface {spec} path {-ca} 

prf {spec} path {-ca} 

same as the append request, but inserts messages at the 
beginning of the ASCII segment specified by path, rather than 
at tne end. 
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previous {-ca} 

prints the number of the previous message of the specified 
type. The control argument may be one of the following: 

- i nc lude__de leted 
-idl 

prints the number of the previous message, whether or not 
it has been deleted, 

-only_deleted 
-odl 

prints the number of the previous deleted message. 

-only_non_deleted 
-ondl 

prints the number of the previous non-deleted message. 
This is the default. 

[previous {-ca}] 

returns the number of the previous message of the specified 
type. If there is no message of the specified type, the 
value zero is returned. This active request takes the same 
control arguments as the previous request. 

print {spec} {-selca} {-ca} 

pr {spec} {-selca} {-ca} 

p {spec} {-selca} {-ca} 

prints the specified messages. This request causes the 
specified messages to be acknowledged, if requested by the 
sender, unless -no__ac knowledge is specified on the read_mail 
command line. 

If you use this request while in the video system (documented 
in The Mult ics Menu System , Order No. CP51), the reset_more 
control order is issued after each message is printed. This 
allows users of the video system to easily abort the printing 
of a single message, when printing several messages. 

Control arguments may be chosen from the following: 

-delete 
-dl 

deletes the specified messages upon exiting read_mail, if 
all the specified messages are successfully printed, 

-header 
-he 

prints complete message headers with the message text. 
This is the default. 
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-include__deleted 
-idl 

prints the messages, whether or not they have been 
deleted. 

no_delete 
-ndl 

does not delete the specified messages upon exiting 
read_mail. This is the default. 

-no__header 
-nhe 

prints an abbreviated form of the message header. 

-no^reverse 
-nrv 

prints the messages in ascending numeric order. This is 
the default. 

-only_deleted 
-odl 

prints only the deleted messages. 

-only_non__deleted 
-ondl 

prints the non-deleted messages. This is the default. 

-reverse 
-rev 

prints messages in reverse order, 

print_header {spec} {-selca} {-ca} 

prhe {spec} {-selca} {-ca} 

prints only the header of the specified message. This 
request causes the specified messages to be acknowledged if 
requested by the sender, unless -no__ac knowledge is specified 
on the read__mail command line. Control arguments are the 
same as for the print request, except that the print_header 
request does not take the -header and -no__header control 
arguments. 

quit {-ca} 
q {-ca} 

exits the read_mail command; any requested deletions are 
actually performed at this point. Control arguments may be 
chosen from the following: 
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-delete 
-dl 

deletes, the specified messages upon exiting read__mail. 
This is the default. 

-force 
-fc 

does not check for newly arrived messages before 
returning to command level. 

no__delete 
-ndl 

does not delete the specified messages upon exiting 
read__mail . 

-no_f orce 
-nf c 

queries the user for permission to exit read__mail if 
there are newly arrived messages. This is the default. 

ready 
rdy 

prints a Multics ready message. The Multics general_ready 
command may be used to change the format of the ready message 
printed by this request, and also after execution of request 
lines if the ready__on request is used. The default ready 
message gives the time of day, the amount of CPU time, and 
page faults used since the last ready message was typed. 

ready_of f 
rdf 

does not generate a ready message after the execution of each 
request line. This is the default. 

ready_on 
rdn 

causes a ready message to be printed after the execution of 
each request line. 

reply {spec} {-ca} {-to addresses} {-ca more__addresses} 
rp {spec} {-ca} {-to addresses} {-ca more_addresses} 

allows the user to reply to the specified messages. By 
default, the reply is sent only to the authors of the 
original messages. The reply is created in send_mail; the 
user is returned to read__mail after the message is sent. 
This request acknowledges any messages requiring 
acknowledgement unless -no__acknowledge is specified on the 
read__mail command line. 

Control arguments for the reply request are: 
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-cc addresses 

sends a copy of the reply to the specified addresses. 
The given addresses become the only secondary recipients 
of the reply unless the -include_recipients control 
argument is also included. 

-delete 
-dl 

deletes the messages after replying to them. However, if 
you exit send_mail . without sending the reply, this 
control argument is ignored. 

-include_authors 
-iat 

includes the authors of the original messages as primary 
recipients of the new message. This is the default, 
unless -to is also specified, in which case this argument 
must be explicitly specified if the authors are to 
receive the reply. 

-include_deleted 
-idl 

includes all messages in the mailbox, whether or not they 
have been deleted, when processing the message__spec i f iers 
to determine which messages will be answered. 

-include_or iginal 
-io 

includes the text and the Date, From, and Subject fields 
of the messages being replied to in the reply. This text 
is indented four spaces if no indentation is explicitly 
specified. 

-include_recipients 
-ire 

includes all recipients of the original message as 
secondary recipients of the reply. 

-include_self 
-is 

allows a copy of the reply to be sent to the writer of 
the reply if it is determined that such a copy should be 
sent from the use of the -include_authors or 
-include__recipients control arguments. 

-indent N 
-ind N 

indents the text of the original message by N spaces in 
the reply. The default is 4 spaces. 
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-no__delete 
-ndl 

does not delete the messages. This is the default. 

-no_include_authors 
-niat 

does not include the authors of the message as primary 
recipients. 

-no_include__original 
-nio 

does not include the original messages. This is the 
default. 

-no__include_recipients 
-nirc 

does not include the recipients of the message as 
secondary recipients. This is the default. 

-no_include__self 
-nis 

specifies that a copy of the reply is sent to the writer 
of the reply only if this is explicitly requested by use 
of the -to or -cc control arguments. This is the 
default. This default allows the user to create a reply 
abbreviation that automatically logs the reply without 
receiving an extra copy whenever -include_recipients is 
specified. 

-no_ref ill 
-nrf i 

does not reformat the original text. This is the 
default. 

-only_deleted 
-odl 

includes only deleted messages when processing the 
message__specif iers to determine which messages will be 
answered. 

-only__non__deleted 
-ondl 

includes only non-deleted messages when processing the 
message__spec i f iers to determine which messages will be 
answered. This is the default. 

-refill 
-rf i 

reformats the original text to fit within the line length 
of the reply. 
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-to addresses 

sends a copy of the reply to the specified addresses. 
The -to control argument overrides the -include_authors 
default, so the given addresses become the only primary 
recipients of the reply unless the -include_authors 
control argument is also included. 

The following send_mail control arguments can also be used on 
the reply request line: 



•abbrev, -ab 
•abort 

•acknowledge, -ack 
•brief, -bf 
-fill, -fi 
■from addresses 
■input_file path, -if path 
•line_length N, -11 N 
■log 

■long, -Ig 
■message_id, -mid 
■no_abbrev, -nab 

-no_abort 

-no__acknowledge , -nack 



-no__fill, -nfi 
-no_log 

-no_message_id, -nmid 
-no_prompt 

-no_request_loop, -nrql 
-no_subject, -nsj 
-prof ile_path, -pf path 
-prompt STR 

-reply_to addr, -rpt addr 
-request STR, -rq STR 
-request__loop, -rql 
-save path, -sv path 
-subject STR, -sj STR 
-terminal__input , -ti 



(For the -reply_to control argument in the above list, "addr" 
means "addresses".) 

Notes on recipients: 

By default, the reply is sent only to the authors of the 
original messages or to those recipients specified by the 
authors to receive replies in place of the authors. In the 
following text, the term "authors of the original messages" 
means either the authors or their designated agents. 

The -to and -include__authors control arguments specify the 
primary recipients for the reply. If the -to control 
argument is used and -include_authors does not appear on the 
request line, only those addresses specified after -to are 
used as the primary recipients of the reply. If both -to and 
-include_authors are used on the request line, the primary 
recipients of the message are the authors of the original 
messages and the addresses specified after the -to control 
argument. Use of -include__authors on the read_mail command 
line does not affect this interaction of -to and 
-include_authors on the reply request line. 

The -cc and -include_recipients control arguments specify the 
secondary recipients for the reply. If -include__recipients 
is specified either on the reply request line or the 
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read_mail command line, all recipients of the original 
messages are included as secondary recipients of the reply. 
If -cc is used on the request line, the addresses following 
the -cc control argument are added to the list of secondary 
recipients of the reply. For example, the command line: 



read_mail -include__recipients 



in conjunction with the request line 



i reply -to Smith. Proj -cc Riley. Proj j 

J L 

composes a reply for the current message that is sent to 
Smith. Proj as the sole primary recipient and to all the 
recipients of the current message plus Riley. Proj as the 
secondary recipients. 

Notes : 

Unless overriden by use of the -abbrev, -no^abbrev, or 
-profile control arguments, the send__mail invocation created 
by this request has the same state of request line 
abbreviation expansion and uses the same profile as the 
current read_mail invocation. 

Unless overriden by use of the -subject or -no_subject 
control arguments, this request constructs a subject for the 
reply message by combining the subjects of all the original 
messages. Additionally, the subject is prefixed by the 
string "Re: ". 

This request constructs an In-Reply-To field for the reply 
message identifying the original messages being answered by 
this reply. 

retrieve {spec} {-selca} 

rt {spec} {-selca} 

causes the specified messages, if deleted, to be undeleted. 
This action is allowed until the user quits and returns to 
command level. When the user exits read_mail, all messages 
deleted by the delete (dl) request are actually deleted from 
the mailbox and can no longer be retrieved. 
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save {spec} path {-ca} 

sv {spec} path {-ca} 

saves the specified messages in the mailbox designated by 
path. The .sv.mbx suffix is added to path if it is not 
present. If the savebox does not exist, the user is asked 
whether to create it. Date and From fields are automatically 
added to any messages that do not have them. If no messages 
are specified, the current one is saved. This request causes 
the specified messages to be acknowledged if requested by the 
senders, unless -no__ac knowledge is specified on the read__mail 
command line. Control arguments are the same as for the 
append request. 

subsystem__name 

prints the name of the current subsystem. 

[ subsystem_name ] 

returns the name of the current subsystem. This active 
request is useful as part of an abbrev that is shared by 
multiple subsystems. 

subsystem_version 

prints the version of the current subsystem. 

[subsystem_version] 

returns the version of the current subsystem, 
request may be used in an abbrev that is shared 
subsystems. 

write {spec} path {-ca} 

w {spec} path {-ca} 

appends the specified messages to the ASCII segment 
designated by path. The .mail suffix is added to path if it 
is not present. If no messages are specified, the current 
one is written. Date and From fields are added to any 
messages that do not have them. This request causes the 
specified messages to be acknowledged if requested by the 
senders unless -no_acknowledge is specified on the read_mail 
command line. Control arguments may be chosen from the 
following: 

-delete 
-dl 

deletes the messages after writing them, if all the write 
operations are successful. 

-extend 

writes the messages at the end of the segment. This is 
♦he default. 



This active 
by multiple 
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-include_deleted 
-idl 

writes the messages, whether or not they have been 
deleted. 

-no_delete 
-ndl 

does not delete the messages after writing them. This is 
the default. 

-no__reverse 
-nrv 

writes the messages in ascending numeric order. This is 
the default. 

-only deleted 
-odl 

writes only the deleted messages. 

-only_non_deleted 
-ondl 

writes the non-deleted messages. This is the default. 

-reverse 
-rev 

writes the messages in reverse order. 

-truncate 
-tc 

truncates the segment before writing the messages to it. 
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send__mail (sdm) 

The send_mail command transmits a message to one or more 
recipients. The message is automatically prefixed by a header 
whose standard fields give the author(s), the intended 
recipients, and a brief summary of the contents. 



SYNTAX AS A COMMAND 

sdm {addresses} {-ca} 



ARGUMENTS 



addresses 

specifies the primary recipients of the message. By default, 
the message has no primary recipients. Addresses may be 
specified in one or more of the following forms: 

-log 

specifies the user's logbox and is equivalent to: 

-mailbox >udd>Project_id>Person_id>Person_id. sv.mbx 

-mailbox PATH 
-mbx PATH 

specifies the pathname of a mailbox. The .mbx suffix is 
assumed if it is not present. 

-save PATH 
-sv PATH 

specifies the pathname of a savebox. The .sv.mbx suffix 
is assumed. 

-user Person_id.Project_id 

specifies the given user's default mailbox. This control 
argument is equivalent to: 

-mailbox >udd>Project_id>Person_id>Person_id. sv.mbx 

STR 

is any non-control argument. If STR contains either "<" 
or ">", it is interpreted as -mailbox STR. Otherwise, it 
is interpreted as -user STR. 

STR -at System 

"s valid only on systems connected to the ARPA network 
and specifies an address on another computer system. STR 
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identifies the user (or group of users) to receive the 
message; it is not interpreted in any way by the local 
system. System identifies a remote system defined in the 
local system's host table; no distinction is made between 
upper and lower case characters in the host name. 

-comment STR 
-com STR 

must appear immediately following one of the above forms 
of an address; it supplies additional descriptive 
information about the address such as a user*s full name. 



CONTROL ARGUMENTS 



Control arguments can be interspersed with the addresses and 
can be chosen from the following: 

-abbrev 
-ab 

enables abbreviation expansion of request lines, 
-abort 

does not send the message unless it can be successfully 
delivered to all specified recipients. This is the default. 

-acknowledge 
-ack 

requests that a message be sent to the user of send__mail by 
each recipient of the message after they have read the 
message via read_mail or print_mail. The sender's name is 
placed in the Acknowledge-To header field. 

-brief 
-bf 

suppresses printing of the message "Mail delivered to 
<address>" when mail is sent. 

-cc addresses 

adds subsequent addresses as secondary recipients of the 
message. Mail is sent to these addresses when the send 
request is issued with no arguments. These addresses are 
placed in the cc header field. In the default case there are 
no secondary recipients. 

-fill 
-f i 

reformats the text of the message according to "fill-on" and 
"align-left" modes of the compose command. The message is 
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reformatted after initial input is completed, and after each 
execution of the qedx and apply requests. This is the 
default for terminal input. 

-from addresses 

adds subsequent addresses as authors of the message. These 
addresses are placed in the From header field, overriding the 
sender's name (placed there by default), and are used as 
recipients of a reply request. 

-header 
-he 

generates a message header. This is the default. 

-in_reply_to STR 
-irt STR 

places STR in the In-Reply-To field of the header. In the 
default case this field is not present. 

-input_file path 
-if path 

sends the text of a segment. Use of this control arguments 
implies -rql. If -input_file is not specified, the user is 
prompted for the message text ("Message:"). 

-line_length N 
-11 N 

specifies a line length to be used when adjusting text. The 
default line length is 72 characters. 

-long 
-Ig 

prints the "Mail delivered to <address>" message when mail is 
sent. This is the default. 

-message__id 
-mid 

adds a Message-ID field to the header, containing a unique 
identifier for the message. 

-no_abbrev 
-nab 

does not enable abbreviation expansion of request lines. 
This is the default. 

-no__abort 

sends the message to as many recipients as possible, even if 
it cannot be sent to all specified recipients. 
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-no_ac knowledge 
-nack 

does not request that recipients of the message acknowledge 
the message. This is the default. 

-no fill 
-nfl 

sends the message as typed with no formatting adjustments, 
unless the fill request or the -fill control argument of the 
qedx and appy requests is used. This is the default for file 
input . 

-no__header 
-nhe 

does not add the normal message header to the message. Only 
the Subject and To header fields are added unless explicitly 
requested by control arguments or requests. 

-no_log 

does not send a copy of the message to the user's logbox. 
This is the default. 

-no_message__id 
-nmid 

does not add a Message-ID field to the header. This is the 
default . 

-no_prompt 

does not prompt for request lines when inside the request 
loop. The default prompt is "send_mail (N) : " , where N is the 
recursion level if greater than one. 

-no_request_loop 
-nrql 

sends the message upon completion of input without entering 
the request loop, unless input is from a terminal and is 
terminated by "\f" or "Xq". This is the default for terminal 
input . 

-no__subject 
-nsj 

does not add a Subject field to the header. 

-profile path 
-pf path 

specifies the pathname of the profile to use for abbreviation 
expansion. The suffix "profile" is added if necessary. This 
control argument implies -abbrev. 
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-prompt STR 

sets the prompt for the request loop to the ioa_ control 
string STR. If STR is the user is not prompted. 

-reply__to addresses 
-rpt addresses 

adds subsequent addresses to the Reply-To header field. In 
the default case this field is not present. When present, 
these addresses are used as recipients of a reply request, 
rather than the addresses of the From field. 

-request STR 
-rq STR 

executes a line of requests specified by STR, after reading 
the message text from the appropriate source. If the quit 
(q) request is not included in STR, the request loop is 
entered after STR is executed. 

-request_loop 
-rql 

enters send_mail's request loop after reading the message 
text. This is the default for file input. 

-subject STR 
-sj STR 

places STR in the Subject field of the header. If STR is 
no Subject field is created. If this control argument is not 
specified, the user is asked for a subject with the prompt 
"Subject:". A blank response causes the Subject field to be 
omitted. 

-terminal__input 
-ti 

prompts the user for the message text ("Message:"). The user 
then types the message text terminated by a line consisting 
of a period {"."). This is the default. 

-to addresses 

adds subsequent addresses as primary recipients of the 
message. These addresses, along with the addresses at the 
beginning of the command line (preceding any control 
arguments), are placed in the To header field. Mail is sent 
to these recipients when the send request is issued with no 
arguments. There are no primary recipients by default. 
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NOTES 



If conflicting control arguments (for instance, -header and 
-no_header) are specified, the last one takes effect. 



Terminal Input 

By default or if -terminal__input is specified, send__mail 
issues the prompt "Message:" and reads the message text from the 
terminal . 

If the user terminates the text with a line containing just a 
period {,), send__mail reformats the message unless -no__fill was 
given on the command line. It then sends the message to the 
specified recipients, unless -request or -request^loop was also 
given on the command line. If any errors occur while sending the 
message, send__mail enters its request loop to allow the user to 
correct the problem. 

If the user terminates the text with a line containing "\f" 
anywhere on the line, send_mail enters the qedx editor. Any 
characters on the line after the "Xf" are treated as qedx 
requests . 

If the user terminates the text with a line containing "\q" 
anywhere on the line, send_mail reformats the message (unless 
-no_fill is given on the command line), and enters the request 
loop. Any characters on the line after the "\q" are ignored with 
a warning message. Type "help qedx" within send_mail for more 
information on the qedx request. 



Addresses 

Any addresses appearing on the command line before the first 
-cc , -from, -reply_to, or -to control argument are considered 
primary recipients of the message. (See the description of the 
-to control argument.) 

The -cc , -from, -reply_to, and -to control arguments apply to 
all subsequent addresses until the next of these control 
arguments is given. Any other intervening control arguments do 
not affect this interpretation. 

For example, the sequence: 
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I addrl -from addr2 addrS ~cc addr4 -to addrS j 
J L 

causes addrl and addrS to be processed by -to, addr2 and addr3 to 
be processed by -from, and addr4 to be processed by -cc. 



Headers 

Each message in a mailbox includes a header containing 
information about who sent the message, when the message was 
sent, etc. The message header is composed of header fields. 
Each field contains its name, a colon, and the contents of the 
field. The header is separated from the actual text of the 
message by one or more blank lines. 

The following group of fields are used by the Multics mail 
system. Additional fields may be present in a message's header 
for use by subsystems that use the mail system to store and 
transfer information. Among the standard fields, only the Date 
and From fields are always present in a message; all other fields 
are optional. The fields are presented in the order that they 
actually appear in a header. 

Date: 

specifies the date and time that the message was created. Its 
format is: 



I Date: DOW, MM Month YYYY HH:MM zzz | 
J L 

where DOW is the day of the week (eg: Monday), "MM" is the day 
of the month, "YYYY" is the year, "HH:MM" is the time, and "222" 
is the time 2one. For example: 



I Date: Thursday, 9 April 1982 19:43 est 

J 



From: 

specifies the authors of the message. Its format is: 
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j From: address-list j 
J L 

where address-list is one or more addresses separated by commas. 
Each address in the list identifies one of the authors of the 
message. 

Subjects 

gives a brief description of the content of the message. Its 
format is: 



j Subject: STR j 
J L 

where STR is the text of the subject of the message. 
Sender : 

identifies the user who sent the message. It is present if there 
is more than one address in the From field, or if the single 
address in the From field does not identify the user who actually 
sent the message (e.g., a secretary sending mail on behalf of a 
manager). Its format is: 



j Sender: address { 
J L 

Reply-To: 

specifies the recipient(s) of any reply to this message. If this 

field is not present, the reply is sent to the authors of the 

message identified in the From field. Its format is: 



Reply-To: address-list 



To: 

specifies the primary recipients of this message. Its format is: 



To: address-list j 
L 
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where each address in the list identifies one of the primary 
recipients of the message. 

cc : 

specifies the secondary recipients of the message. Its format 
is: 



j cc: address-list j 
J L 

where each address in the list identifies one of the secondary 
recipients of the message. 

bcc : 

identifies the tertiary recipients of the message (i.e., those 
who receive a "blind" copy). Its format is: 



bcc: address 



where address identifies the tertiary recipient who received this 
copy of the message. The copy of a message delivered to the 
primary and secondary recipients never includes a bcc field. 

Acknowledge-To: 

identifies the user to whom acknowledgements of the receipt of 
this message are to be sent. This field is only present in 
copies of the message which have not yet been acknowledged. Its 
format is: 



j Acknowledge-To: address j 
J '. L 

I n-Reply-To: 

identifies the message(s) to which this message is a reply. Its 
format is: 



I I 
j In-Reply-To: STRl , STR2, ... STRn j 

J . L 

where each STRi identifies one of the messages for which this 
message is a reply. The format of STR looks like this: 
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j Message of 18 June 1982 12:23 est from Spry.Proj | 
J L 

where "Spry.Proj" identifies the author of the original message, 
and the rest of the line identifies the date and time when the 
original message was created. 

Message-ID: 

uniquely identifies this message. Its format is: 



I Message-ID: <y YMMDDHHMMSS • FFFFFF> j 

J L 

where "YYMMDDHHMMSS .FFFFFF" is the request ID representing the 
time when this message was first created. For a description of 
request IDs, see the Reference manual. 

There are two groups of header fields that appear optionally. 
When present, the Forwardings and comments header fields appear 
after the above standard fields and any non-standard fields in 
the header. These groups may be present in the header more than 
once; each occurrence of such a group identifies a single 
forwarding or commenting of the message. 

The group of fields containing forwarding information 
indicates that this message was redistributed (forwarded) by one 
of its recipients to one or more additional recipients. If 
present, the Comment field contains any comments the recipient 
added at the time they forwarded the message. The format of this 
group is: 



Redistributed-Date: DD Month YYYY HH:MM zzz 
Redistr ibuted-By : address 
Redistributed-To: address-list 
Comment: STR 



where "DD Month YYYY HH:MM zzz" indicates the date and time when 
the message was forwarded, address identifies the individual who 
forwarded the message, and the addresses in the address-list 
indicate to whom the message was forwarded. 

The Comment fields indicates that a comment was added to this 
message. The format of this group is: 
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Comment-Date: DD Month YYYY HHsMM zzz 
Comment-By: address 
Comment: STR 



where "DD Month YYYY HH:MM zzz" specifies the date and time that 
the comment was added, address identifies the user who added the 
comment, and STR is the actual text of the comment. 



REQUESTS 

In the following send_mail request descriptions, "spec" means 
"message_specif ier" , "-ca" means "-control_args" , and "-selca" 
means "-selection_args" . See the read_mail description for 
information on message specifiers and selection arguments. 

7 

prints a multi-columnar list of the send_mail requests. 



prints a line identifying the current version of send_mail 
and the current state of the message being created: 



j send_mail 6.0: 23 lines (modified) Subject: Zoots j 
J L 

The word "modified" indicates that the message has been 
changed since the last use of the send request. The string 
"send_mail 6.0" gives the version number of send_mail. If 
the current recursion level is greater than one, it is 
included in parentheses, for example: 



I 

I send__mail 6.0 (level 2): 5 lines: 
J 



If abbrev expansion is enabled, the word "abbrev" is included 
in parentheses before the recursion level (if any): 



rend__mail 6.0 (abbrev) (level 2): 5 lines 
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.. STR 

passes a command line, specified by STR, directly to the 
command processor, without processing by the send_mail 
request processor. The string must be the first two 

characters of the request line. 

abbrev {-ca} 
ab {-ca} 

controls abbreviation processing within send__mail. If 
invoked with no arguments, this request enables abbrev 
processing within send_mail using the profile that was last 
used in this send__mail invocation. If abbrev processing was 
not previously enabled, the profile in use at Multics command 
level is used; this profile is normally 

[home dir]>Person. id.prof ile. (See the Commands manual for a 
descrTption of abbreviation processing.) Control arguments 
may be chosen from the following: 

-off 

specifies that abbreviations are not to be expanded. 

-on 

specifies that abbreviations are expanded. This is the 
default . 

-profile path 

specifies that the segment named by path is to be used as 
the profile segment. The suffix ".profile" is added to 
path if it is not present. The segment named by path 
must exist prior to the use of this control argument. 

[abbrev] 

returns "true" if abbreviation expansion of request lines is 
currently enabled within send__mail, and "false" otherwise. 

answer STR {-ca} request__line 

provides preset answers to questions asked by another 
request. The arguments are: 

STR 

is the desired answer to any question. If the answer is 
more than one word, it must be enclosed in quotes. If 
STR is -query, the question is passed on to the user. 
The -query control argument is the only one that can be 
used in place of STR. 

request_line 

is any send_mail request line. It can contain any number 
of separate arguments (i.e., have spaces within it) and 
need not be enclosed in quotes. 
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Control arguments may be chosen from the following: 

-brief 
-bf 

suppresses printing (on the user's terminal) of both the 
question and the answer. 

-call STR 

evaluates the active string STR to obtain the next answer 
in a sequence. The active string is constructed from 
send_mail active requests and Multics active strings 
(using send__mail's "execute" active request). The 
outermost level of brackets must be omitted and the 
entire string must be enclosed in quotes if it contains 
request processor special characters. The return value 
"true" is translated to "yes", and "false" to "no". All 
other return values are passed as is. 

-exclude STR 

-ex STR 

passes on, to the user or other handler, questions whose 
text matches STR. If STR is surrounded by slashes (/) , 
it is interpreted as a qedx regular expression. 
Otherwise, answer tests whether STR is literally 
contained in the text of the question. Multiple 
occurrences of -match and -exclude are allowed (see 
"Notes" below). They apply to the entire request line. 

-match STR 

answers only questions whose text matches STR. If STR is 
surrounded by slashes {/), it is interpreted as a qedx 
regular expression. Otherwise, answer tests whether STR 
is literally contained in the text of the question. 
Multiple occurrences of -match and -exclude are allowed 
(see "Notes" below). They apply to the entire request 
line. 

-query 

skips the next answer in a sequence, passing the question 
on to the user. The answer is read from the user_i/o I/O 
switch. 

-then STR 

supplies the next answer in a sequence, 
-times N 

gives the previous answer (STR, -then STR, or -query) N 
times only (where N is an integer). 
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Answer provides preset responses to questions by establishing 
an on unit for the condition command_question , and then 
executing the designated request line. If any request in the 
request line calls the command_query__ subroutine (described 
in the Subroutines manual) to ask a question, the on unit is 
invoked to supply the answer. The on unit is reverted when 
the answer request returns to send_mail request level. See 
the Reference manual for a discussion of the command_question 
condition. 

If a question is asked that requires a yes or no answer, and 
the preset answer is neither "yes" nor "no", the on unit is 
not invoked. 

The last answer specified is issued as many times as 
necessary, unless followed by the -times N control argument. 

The -match and -exclude control arguments are applied in the 
order specified. Each -match causes a given question to be 
answered if it matches STR; each -exclude causes it to be 
passed on if it matches STR. A question that has been 
excluded by the -exclude control argument is reconsidered if 
it matches a -match later in the request line. 

append path 
app path 

appends the message (with header) to the end of the ASCII 
segment specified by path. The suffix .mail is added to path 
if it is not present. If the specified segment does not 
already exist, the user is asked whether to create it. 

apply {"ca} STR 
ap {-ca} STR 

places the message in a temporary segment in the process 
directory, then concatenates the command line specified by 
STR with intervening spaces and appends the pathname of the 
temporary segment. This concatenated command line is passed 
to the Multics command processor. When the command line has 
completed, the message in send__mail is replaced with the 
contents of the temporary segment. This request can be used 
to edit the message with a text editor. Control arguments 
are: 

-fill 
-f i 

specifies that the message text is reformatted after the 
command line has been executed. 
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-header 
-he 

specifies that the message header is passed to the 
command line in addition to the message text. 

-line_length N 
-11 N 

specifies the line length to use when reformatting the 
message text. If this control argument is not given, the 
line length specified on the send__mail command line is 
used. If no line length is specified on the send__mail 
command line, a line length of 72 is used. 

-no__f ill 
-nf i 

specifies that the message text is not be reformatted. 

-no_header 
-nhe 

specifies that only the message text is passed to the 
command line. This is the default. 

The supplied command line for the apply request need not be 
enclosed in quotes. However, if there are (), [], or "'s in 
the command line that should be processed by the Multics 
command processor, they should be enclosed in quotes to 
prevent processing by send_mail's request processor. 

The message is passed to the Multics command line by placing 
the message text and header (if requested) into a temporary 
segment. The pathname of this segment is appended to the 
command line, which is then executed. The contents of the 
segment after execution replace the prior message text (and 
header) . 

This request may be used to edit the message with an editor 
other than qedx . For example, the following request invokes 
the Emacs text editor on the message text: 

apply emacs 

The default for reformatting the message after execution of 
the command line is dependent on the original source of the 
message text. If terminal input was used, the default is to 
reformat the message; if file input was used, the default is 
to leave the message unformatted. This default may be 
changed by use of the -fill and -no___fill control arguments on 
the send_mail command line. Additionally, whatever default 
is specified may be overriden for one invocation of the apply 
requt;rt by use of the control arguments described above. 
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If the -header control argument is specified, both the 
message header and text are placed in the temporary segment. 

After apply execution is complete, send_mail analyzes the new 
message and then updates the message's subject, In-Reply-To 
field, lists of primary/secondary recipients, authors, and 
list of recipients for future replies. 

cc {addresses} 

adds any addresses specified to the list of secondary 
recipients of the message. Mail is sent to these addresses 
when a subsequent send request is issued with no arguments. 
The addresses are added to the cc field, which is created if 
necessary. If no addresses are specified, the secondary 
recipients of the message are listed. 

copy path 
cp path 

copies the message into the mailbox designated by path. The 
mailbox must already exist. The .mbx suffix is added to path 
if it is not present. 

do STR {args} 
or 

do {-ca} 

expands a request line specified by STR by substituting the 
supplied arguments into the line before execution. Arguments 
are character string arguments that replace parameters in the 
request line. 

The following control arguments set the mode of operation of 
the do request: 

-absentee 

an any^other handler is established 
conditions and aborts execution of 
without aborting the process. 

-brief 
-bf 

the expanded request line is not printed before 
execution. This is the default. 

-go 

the expanded request line is passed on for execution. 
This is the default. 

-interactive 

the any_other handler is not established. This is the 
default . 



that catches all 
the request line 
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-long 

the expanded request line is printed before execution, 
-nogo 

the expanded request line is not passed on for execution. 

Any sequence beginning with & in the request line is expanded 
by the do request using the arguments given on the request 
line. Following is the list of parameters: 

&I 

is replaced by argi , I must be a digit from 1 to 9. 

&(I) 

is also replaced by argI . I can be any value, however. 

&ql 

is replaced by argI with any quotes in argI doubled. I 
must be a digit from 1 to 9. 

Scq(I) 

is also replaced by argI with any quotes doubled. I can 
be any value. 

&rl 

is replaced by all the arguments starting with argI . 
Each argument is placed in quotes with contained quotes 
doubled. I must be a digit from 1 to 9. 

&r(I) 

is also replaced by a requoted argI . I can be any value. 

Scfl 

is replaced by all the arguments starting with argI . I 
must be a digit from 1 to 9. 

&f (I) 

is also replaced by all the arguments starting with argI . 
I can be any value. 

fitqf I 

is replaced by all the arguments starting with argI with 
any quotes doubled. I must be a digit from 1 to 9. 

&qf (I) 

is also replaced by all the arguments starting with argI 
with quotes doubled. I can be any value. 
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&rf (I) 

is also replaced by all the arguments starting with argi , 
requoted. I can be any value. 

&& 

is replaced by an ampersand. 

&! 

is replaced by a 15 character unique string. The string 
used is the same everywhere &! appears in the request 
line. 

&n 

is replaced by the actual number of arguments supplied. 

Stf &n 

is replaced by the last argument supplied. 

[do request_line {args}] 

returns a request line with argument substitution. 

exec_com path {args} 
ec path {args} 

executes a program written in the exec_com language, where 
path is the pathname of an exec_com program. The suffix 
"sdmec" is added to the pathname if necessary. This program 
is used to pass request lines to send_mail and to pass input 
lines to requests which read input. The arguments are 
optional arguments to the exec^com program and are 
substituted for parameter references in the program such as 

Scl. 

If the pathname does not contain a "<" or">" character, 
send_mail searches for the exec_com program using the 
mail_system search list. The default content of this search 
list is: 



j -working__dir j 
I >udd>[user project ]>[user name]>[user name].mlsys j 

J L 

When evaluating a send_mail exec__com program, subsystem 
active requests are used rather than Multics active functions 
when evaluating the &[,..] construct and the active string in 
an &if statement. The send_mail execute active request may 
be used to evaluate Multics active strings within the 
exec com. 
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Currently, any error detected during execution of an exec_com 
within send__mail aborts the request line in which the 
exec__eojn request was invoked. 

[exec_com path {args}] 

[ec path {args}] 

executes a program written in exec_com language that 
specifies a return value of the exec__com request with the 
&return statement. The arguments are the same as for the 
exec^com request. 

execute STR 
e STR 

executes the supplied line as a Multics command line, where 
STR is the Multics command line to be executed or the Multics 
active string to be evaluated. It need not be enclosed in 
quotes. 

The recommended method to execute a Multics command line from 
within send_mail is the escape sequence. The execute 

request is intended as a means of passing information from 
send_mail to the Multics command processor. 

All (), [], and s in the given line are processed by the 
send_mail request processor, not the Multics command 
processor. Thus, the values of subsystem active requests may 
be passed to Multics commands when using the execute request. 
For example, the send__mail request line: 



I e sm Roe.NewProj I'm sending you mail about [subject], j 
J L 

warns user Roe.NewProj that she is about to receive a 
message. 

[execute STR] 
[e STR] 

the execute active request can be used with a Multics active 
function to invoke the active function from within send_mail. 
For example, the following send__mail request line: 



j write [e date] j 
J L 

writes the ASCII representation of the message being created 
into a segment in the working directory. The entry name of 
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this segment is the current date with a suffix of ".mail" 
(e.g., 12/01/82. mail). 

fill {-ca} 
fi {-ca} 

reformats the message text according to "fill-on" and 
"align-left" modes of the compose command. If the -fill 
control argument, which is the default for terminal input, is 
specified on the send_mail command line, the message is 
reformatted after each use of the qedx and apply requests. 
This automatic reformatting can be overridden by use of the 
-no_fill control argument to these requests. The control 
argument to the fill request is: 

-line__length N 
-11 N 

specifies the maximum line length. The default is 72 
characters, or the value specified with the send_mail 
-line_length control argument. 

from {addresses] 

adds addresses to the list of authors of the message if any 
addresses are specified. The addresses are added to the From 
field of the header. If no addresses are specified, the 
authors of the message are listed. If no explicit authors 
are specified, either via this request or via use of the 
-from control argument on the send_mail command line, the 
user of send_mail is listed as the sole author of the message 
when it is transmitted. If a message has more than one 
author or the author is not the user using send_mail, a 
Sender field identifying the user of send__mail is added to 
the message when it is transmitted. 

help {STR} 

prints information about various send__mail topics, including 
detailed descriptions of send__mail requests. If specified, 
STR is the name of a topic on which information is to be 
printed. If STR is not specified, the help request lists the 
requests that provide information about send_mail. 

The help request accepts most of the control arguments 
accepted by the Multics help command. Type ".. help help" 
for a complete description of the help request. Following is 
a description of some of the more useful control arguments 
for the help request: 
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-brief 
-bf 

prints only a summary of a request or active request, 
including the Syntax section, list of arguments, control 
arguments, etc. 

-search STRs 
-srh STRs 

begins printing with the paragraph containing all the 
strings STRs. By default, printing starts at the 
beginning of the information. 

-section STRs 
-sen STRs 

begins printing at the section whose title contains all 
the strings STRs. By default, printing starts at the 
beginning of the information. 

-title 

prints section titles and section line counts; then asks 
if the user wants to see the first paragraph of 
information. 

The most useful responses to questions asked by the help 
request are: 

prints the list of responses allowed to help queries. 



prints "help" to identify the current interactive 
environment . 

.. command__line 

treats the remainder of the response as a Multics coimnand 
line. 

no 
n 

stops printing information for this topic and proceeds to 
the next topic, if any. 

quit 

q 

stops printing information for this topic and returns to 
the subsystem's request level. 
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rest {-sen} 
r {-sen} 

prints remaining information for this topie without 
intervening questions. If -seetion or -sen is given, 
help prints only the rest of the current seetion without 
questions and then asks if the user wants to see the next 
seetion . 

seareh {STRs} {-top} 

srh {STRs} {-top} 

skips to the next paragraph containing all the strings 
STRs. If -top or -t is given, searching starts at the 
top of the information. If STRs are omitted, help uses 
the STRs from the previous search response or the -search 
control argument. 

seetion {STRs} {-top} 

sen {STRs} {-top} 

skips to the next section whose title contains all the 
strings STRs. If -top or -t is given, title searching 
starts at the top of the information. If STRs are 
omitted, help uses the STRs from the previous section 
response or the -section control argument. 

skip {-sen} {-seen} 

s {-sen} {-seen} 

skips to the next paragraph. If -section or -sen is 
given, help skips all paragraphs of the current section. 
If -seen is given, help skips to the next paragraph which 
the user has not seen. Only one control argument is 
allowed in each skip response. 

title {-top} 

lists titles and line counts of the sections that follow; 
if -top or -t is given, help lists all section titles. 
The previous question is repeated after titles are 
printed. 

yes 

y 

prints the next paragraph of information on this topie. 

if [EXPR] -then LINEl {-else LINE2} 

conditionally executes one of two request lines depending on 
the value of an active string. The arguments are: 

EXPR 

is the active string which must evaluate to either "true" 
or "false". The active string is constructed from 
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send_niaii active requests and Muitics active strings 
(using send_mail's execute active request). 

LINEl 

is the send_mail request line to execute if EXPR 
evaluates to "true". If the request line contains any 
request processor characters, it must be enclosed in 
quotes. 

LINE2 

is the send_mail request line to execute if EXPR 
evaluates to "false". If omitted and EXPR is "false", no 
additional request line is executed. If the request line 
contains any request processor characters, it must be 
enclosed in quotes. 

[if [EXPR] -then STRl {-else STR2}] 

returns one of two character strings to the send_mail request 
processor, depending on the value of an active string. The 
arguments are: 

EXPR 

is the active string that must evaluate to either "true" 
or "false". The active string is constructed from 
send_mail active requests and Muitics active strings 
(using send__mail's execute active request), 

STRl 

is returned as the value of the if active request if the 
EXPR evaluates to "true". 

STR2 

is returned as the value of the if active request if the 
EXPR evaluates to "false". If omitted and the EXPR is 
"false", a null string is returned. 

in_reply_to {STRs} 
irt {STRs} 

replaces the In-Reply-To field of the message (if any) with 
the concatenation of the STRs with intervening spaces. If no 
STRs are specified, it prints the contents of the In-Reply-To 
field. 

list_help {topics} 
Ih {topics} 

displays the name of all send_mail information segments on 
given topics. If no topics are given, all send__mail 
information segments are listed. 
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When matching topics with info segment names, an info segment 
name is considered to match a topic only if that topic is at 
the beginning or end of a word within the segment name. 
Words in info segment names are bounded by the beginning and 
end of the segment name and by the characters period (.), 
hyphen (-), underscore (_) , and dollar sign ($). The ".info" 
suffix is not considered when matching topics, 

list_or iginal {spec} {-selca} {-ca} 

Iso {spec} {-selca} {-ca} 

provides a one-line summary of relevant information about the 
message{s) being answered. This request is only available 
within a send__mail that was created by the read_mail reply 
request. It accepts read__mail message specifiers, so that 
the user can examine other messages which might be relevant 
to the reply. Control arguments are: 

-header 
-he 

preceeds the message listing by a header line that 
identifies the columns of the list. This is the default. 

-include_deleted 
-idl 

includes all messages in the mailbox, whether or not they 
have been deleted, when processing message__specif iers and 
select ion_args to determine which messages will be 
listed, 

-line__length N 
-11 N 

uses the supplied line length when determining where and 
if to truncate the message subject. The default length 
is the terminal's line length, default. 

-no__header 
-nhe 

omits the header line from the listing. 

-no_line_length 
-nil 

does not truncate the message subject unless the subject 
is more than one line long. 

-no_reverse 
-nrv 

lists the messages in ascending numeric order. This is 
the default. 
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-only_deleted 
-odl 

incltjdes only those messages which have been deleted. 

-only_non_deleted 
-ondl 

includes only those messages which have not been deleted. 
This is the default. 

-reverse 
-rv 

lists the messages in descending numeric order. 

If this request was created by the reply request in 
read_mail, you can list any message in the read__mail 
invocation with this request. 

[ list_or iginal {spec} {-selca} {~ca}] 

[Iso {spec} {-selca} {-ca}] 

returns the message numbers of the messages being answered by 
send_mail. This active request is only available within an 
invocation of send_mail that was created by the read_mail 
reply request. It takes the same control arguments as the 
list_or iginal request. 

1 i st_request s {STR} {-ca} 
Ir {STR} {-ca} 

prints a brief description of selected send_mail requests, 
where STR specifies the request{s) to be described. Any 
request with a name containing one of these strings is listed 
unless -exact is used, in which case the request name must 
exactly match one of these strings. When matching STRs with 
request names, a request name is considered to match a STR 
only if that STR is at the beginning or end of a word within 
the request name. Words in request names are bounded by the 
beginning and end of the request name and by the characters 
period (.), hyphen (-), underscore (_) , and dollar sign ($). 

Control arguments are: 

-all 
-a 

includes undocumented and unimplemented requests in the 
list of requests eligible for matching the STR arguments. 

-exact 

lists only those requests one of whose names exactly 
match one of the STR arguments. 



A-71 



CH23-01 



send mail (sdm) 



send_mail (sdm) 



saves a copy of the message in the user's logbox 
(Person_id.sv.mbx) . This request creates the logbox if one 
does not already exist. 

log_original {spec} {-ca} 

logo {spec} {-ca} 

places a copy of the original message(s) into the user's 
logbox. This request is only available within a send_mail 
that was created by the read__mail reply request. It accepts 
read_mail message specifiers, so that the user can log other 
messages which might be relevant to the reply. 

The user's logbox is the mailbox 

>udd>Pro ject__id>Person_id>Person_id, sv.mbx . This mailbox is 
created automatically by the request if it does not already 
exist. The user is informed when the logbox is created. 
This request acknowledges any messages requiring 
acknowledgement unless -no_acknowledge is specified on the 
read_mail command line. 

Control arguments are: 

-include_deleted 
-idl 

includes all messages in the mailbox, whether or not they 
have been deleted, when processing the message_specif iers 
to determine which messages will be logged. 

-only_deleted 
-odl 

includes only those messages which have been deleted. 

-only_non_deleted 
-ondl 

includes only those messages which have not been deleted. 
This is the default. 

-no__reverse 
-nrv 

logs the messages in ascending numeric order. This is 
the default. 

-reverse 
-rv 

logs the messages in descending numeric order. 
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message__id 
mid 

prints the Message-ID field of this message, creating the 
field if necessary. 

preface path 
prf path 

same as the append request, but inserts the message at the 
beginning of the ASCII segment specified by path. 

print {"ca} 

pr {-ca} 
P {-ca} 

prints the message. The control argument may be one of the 
following: 

-br ief_header 
-bfhe 

prints an abbreviated form of the message header, 
including the Subject and To fields. If the message has 

no subject, the Subject line is omitted. If there are no 

primary recipients for the message, the To line contains 

the string <no addresses>. If there is no secondary 

recipient, the cc line is omitted. This is the default. 

-header 
-he 

prints the complete message header with the message. 

-no_header 
-nhe 

does not include a message header with the message text. 

pr int__header {-ca} 
prhe {-ca} 

prints the header of the message. The control argument may 
be one of the following: 

-brief 
-bf 

prints an abbreviated form of the message header, 
including the Subject and To fields. 

-long 
-Ig 

prints the complete message header. This is the default. 
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print_or iginal {spec} {-selca} {-ca} 

pro {spec} {-selca} {-ca} 

prints the original message(s). This request is only 
available within a send_mail that was created by the 
read_mail reply request. It accepts read__mail message 
specifiers, so that the user can examine other messages which 
might be relevant to the reply. This request acknowledges 
any messages requiring acknowledgement unless -no_acknowledge 
is specified on the read_mail command line. It takes the 
same control arguments as the log_original request, and these 
additional control arguments: 

-header 
-he 

prints the full header associated with each message. 

-no_header 
-nhe 

prints a summary of the header associated with each 
message. 

pr int__or iginal_header {spec} {-selca} {-ctl_args} 

prohe {spec} {-selca} {-ctl_args} 

prints message header{s) of the original message(s). This 
request is only available within a send_mail that was created 
by the read__mail reply request. It accepts read__mail message 
specifiers, so that the user can examine other messages which 
might be relevant to the reply. This request acknowledges 
any messages requiring acknowledgement unless -no_acknowledge 
is specified on the read__mail command line. It takes the 
same control arguments as the log_original request. 

qedx {-ca} 
qx {-ca} 

invokes the qedx editor to modify the message. The qedx w 
(write) request is not necessary to reflect changes in the 
message to send__mail. The editor request line l,$dr can be 
used to restore the original text. 

The default for reformatting the message after editing is 
dependent on original source of the message text. If 
terminal input was used, the default is to reformat the 
message; if file input was used, the default is to leave the 
message unformatted. This default may be changed by use of 
the -fill and -no__fill control arguments on the send mail 
command line. Additionally, whatever default is specTfied 
may be overriden for one invocation of the qedx request by 
use of the. control arguments described below. 
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If the -header control argument is specified, both the 
message header and text are be given to the editor* After 
editing is complete, send_mail analyzes the new message and 
then updates the message's subject, In-Reply-To field, lists 
of primary/secondary recipients, authors, and list of 
recipients for future replies. 

The control arguments are: 



causes the message text to be reformatted after editing, 

-header 
-he 

both header and text can be edited. 

-line_length N 
-11 N 

specifies the line length of the reformatted text. If 
this control argument is not given, the line length (if 
any) specified on the send_mail command line is used; 
otherwise, a line length of 72 characters is used. 

-no_fill 
-nf i 

specifies that the message text is not reformatted, 
-no header 



only the message text can be edited. This is the 
default . 



quit {-ca} 
q {-ca} 

exits the send_mail command. The control argument can be one 
of the following: 



does not ask about a modified or incomplete message 
before returning to command level. 



causes send_mail to query the user for permission to exit 
if the message has been modified since it was last sent, 
saved, or written. This is the default. 



-fill 
-fi 



-nhe 




-no_f orce 
-nfc 



A-75 



CH23-01 



send_mail (sdm) send_mail (sdm) 



ready 
rdy 

prints a Multics ready message. The Multics general_ready 
command may be used to change the format of the ready message 
printed by this request, and also after execution of request 
lines if the ready on request is used. The default ready 
message gives the time of day, the amount of CPU time, and 
page faults used since the last ready message was typed. 

ready__of f 
rdf 

does not generate a ready message after the execution of each 
request line. This is the default. 

ready_on 
rdn 

prints a ready message after the execution of each request 
line. 

remove {addresses} {-ca} 

rm {addresses} {-ca} 

deletes specified addresses and/or specified header fields. 
All occurrences of the addresses are removed from both the 
list of primary recipients and the list of secondary 
recipients. If no addresses are given, at least one of the 
control arguments described below must be used. New 
recipients, authors, etc. can be added to the message with 
the cc, from, in__reply_to, message__id, reply_to, subject, and 
to requests. Control arguments may be chosen from the 
following : 

-all 
-a 

removes all recipients from the message. This control 
argument must appear before all other control arguments, 
and may not be used if any addresses are specified. 

-cc {addresses} {-ca} 

deletes specified addresses from the cc field, or deletes 
the entire field if -all (-a) is given. Either an 
address or -all must be supplied. 

-from {addresses} {-ca} 

deletes specified addresses from the From field, or 
deletes the entire field if -all {-a) is given. Either 
an address or -all must be supplied. 

-in__reply__to 
-irt 

deletes the In_Reply_To field. 
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-message^^id 
-mid 

deletes the Message_iD field. 

-reply_to {addresses} {-ca} 

deletes specified addresses from the Reply_To field, or 
deletes the entire field if -all (-a) is given. Either 
an address or -all must be supplied. 

-subject 
-sj 

deletes the Subject field. 

-to {addresses} {-ca} 

deletes specified addresses from the To field, or deletes 
the entire field if -all (-a) is given. Either an 
address or -all must be supplied. 

reply_to {addresses} 

rpt {addresses} 

adds addresses of users who are to receive the reply to this 
message. These addresses are also appended to the Reply-To 
field of the header, which is created if necessary. If no 
addresses are specified, read__mail sends replies to this 
message to the authors of the message. 

save path 
sv path 

saves a copy of the message in the indicated savebox. The 
suffix ".sv.mbx" is added to path if not already present. If 
the savebox does not exist, the user is asked whether to 
create it. 

save_original {spec} path {-ca} 

svo {spec} path {-ca} 

saves the original message(s) into a savebox. If the savebox 
identified by the path argument does not exist, the user is 
queried for permission to create it. This request is only 
available within a send^mail that was created by the 
read_mail reply request; any message within the read__mail 
invocation may be saved by this request. Any message 
requiring acknowledgement is acknowledged by this request 
unless -no__acknowledge is specified on the read__mail command 
line. Control arguments for the save__or iginal request are 
the same as for the logger iginal request. 

send {addresses} {-ca} 

transmits the message to the primary and secondary recipients 
if no addresses are specified. If any addresses are 
specified, the message is transmitted only to these 
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addresses, without adding them to the message header. It is 
possible to send "blind" carbon copies by issuing two 
separate send requests; one without addresses to deliver the 
message to the primary and secondary recipients, and a second 
to deliver the message to the blind carbon recipients. 

The following send request control arguments are identical to 
the send_mail command control arguments of the same name: 

-abort -no_abort 

-acknowledge (-ack) -no__ac knowledge (-nack) 

-brief (-bf) -no__header (-nhe) 

-header (-he) -no_message_id (-nmid) 

-long (-Ig) -save path (-sv path) 
-message_id (-mid) 

The above control arguments temporarily override the defaults 
specified on the send_mail command line. 

subject {STRs} 
sj {STRs} 

replaces the Subject field of the message (if any) with the 
concatenation of the STRs with intervening spaces. If no 
STRs are specified, the contents of the Subject field are 
printed instead. 

[ subject] 
[sj] 

returns the contents of the Subject field as a single quoted 
string. 

subsystem__name 

prints the name of the current subsystem. 

[ subsystem__name ] 

returns the name of the current subsystem. This active 
request is useful as part of an abbrev which is shared by 
multiple subsystems. 

subsystem__version 

prints the version of the current subsystem. 

[ subsystem_version ] 

returns the version of the current subsystem. This active 
request may be used in an abbrev which is shared by multiple 
subsystems. 

to {addresses} 

adds addresses to the list of primary recipients of the 
message or prints the contents of the list. When a 
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subsequent send request is issued with no arguments, mail is 
sent to the addresses in the primary and secondary recipient 
lists. The addresses are added to the To field of the 
header, which is created if necessary. If no addresses are 
specified, the primary recipients of the message are listed. 

write path {-ca} 

appends the message (with header) to the ASCII segment 
designated by path. The suffix .mail is added to path if it 
is not present. The segment is created if necessary. The 
control argument may be one of the following: 

-extend 
-ex 

appends the message to the end of the segment. This is 
the default. 



-truncate 
-tc 

truncates the segment before writing the message to it. 

wr ite_or iginal {spec} path {-ca} 

wo {spec} path {-ca} 

writes the original message(s) into an ASCII segment 
specified by path. This request is only available within a 
send__mail that was created by the read__mail reply request; 
any message within the read__mail invocation may be written by 
this request. Any message requiring acknowledgement is 
acknowledged by this request unless -no_acknowledge is 
specified on the read_mail command line. The write_or iginal 
request takes the same control arguments as the log__or iginal 
request, and the following additional control arguments; 

-extend 

writes the messages at the end of the segment if there is 
already data present in the segment. This is the 
default . 



-truncate 
-tc 

truncates the segment before writing the messages. 
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MAILBOX COMMANDS 



The mailbox access commands and the mbx__create command are 
documented in this appendix. Extended access provides a way to 
further your control over your mailboxes. 

The extended access modes for mailboxes are: 

add (a) add a message 

delete (d) delete any message 

read (r) read any message 

own (o) read or delete only your own messages; 

that is, those sent by you 

status (s) find out how many messages are in the 

mailbox 

wakeup (w) can send a wakeup indicating that a 

message was added to the mailbox 

The extended access placed on a new mailbox is: 

adrosw user who created the mailbox 

aow * .SysDaemon.* 

aow 

Users have full (adrosw) access to their personal mailbox 
(Person_id.mbx) , 

When assigning or removing access to your mailboxes for other 
users, User_ids are used. The matching strategy for access 
control names is as follows: 

1. A literal component name, including matches only a 

component of the same name. 
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2. A missing component name not delimited by a period is 
taken to be a literal e.g., "*.Multics" is treated as 

"* .Multics . *" ) . Missing components on the left must be 
delimited by periods. 

3. A missing component name delimited by a period matches 
any component name. 

Some examples of access names and which ACL entries they match 
ares 

*.*.* matches only the ACL entry "*.*•*". 

Multics matches only the ACL entry "Multics.*,*". 

absence of a leading period makes 
Multics the first component. 

.Multics matches every ACL entry with middle 

component of Multics. 

matches every ACL entry. 

matches every ACL entry with a last 
component of "*", 

"" (null string) matches every entry ending in 
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mbx_create (mbcr) 

The mbx_create command creates a mailbox with a specified 
name in a specified directory. 



SYNTAX AS A COMMAND 
mbx_create paths 



ARGUMENTS 



paths 

are the pathnames of mailboxes to be created. If pathi^ 
does not have the .mbx suffix, one is assumed. 



NOTES 



The user must have modify and append permission on the 
directory in which he is creating a mailbox. 

If the creation of a mailbox introduces a duplication of 
names within the directory, and if the old mailbox has only one 
name, the user is asked for permission to delete the old mailbox. 
If the answer is "no", no action is taken. If the old mailbox 
has multiple names, the conflicting name is removed and a message 
to that effect is issued to the user. 

See also the mbx_set_acl command in this appendix. 



EXAMPLES 

The command line: 

! mbcr Green Kogan.home >udd>Multics>Giliis>Gillis 

creates the mailboxes Green. mbx and Hogan .home .mbx in the working 
directory and creates the mailbox Gillis.mbx in the directory 
>udd>Multics>Gillis. 



B-3 



CH23-01 



mbx_delete_acl (mbda) mbx_delete_acl (mbda) 



mbx_delete_acl (mbda) 

The mbx_delete__acl command deletes entries from the access 
control list (ACL) of a given mailbox. 

SYNTAX AS A COMMAND 

mbx__delete_acl path {User_ids} {-control_args} 

ARGUMENTS 

path 

is the pathname of a mailbox. The .mbx suffix is assumed 
if not supplied. The star convention is allowed. 

User_ids 

are access control names of the form 

Person_id.Pro ject__id. tag . All entries with matching 

names are deleted. If no User_ids are given, the user's 
own is assumed. 

CONTROL ARGUMENTS 

-all 
-a 

deletes all entries except for *.*.*. 

-brief 
-bf 

suppresses the messages "User name not on ACL" and "Empty 
ACL". 

-chase 

chases links when using the star convention. 
-no__chase 

does not chase links when using the star convention. 
This is the default. 



NOTES 

The user must have modify permission on the containing 
directory. 

See the beginning of this appendix for an explanation of 
User__id matching strategy. 
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mbx_list_acl (mbla) 

The mbx list^acl command lists entries on the access control 
lists of maTlboxes. 



SYNTAX AS A COMMAND 

mbx_list_acl path {User_ids} {-control_args} 



ARGUMENTS 



path 

is the pathname of a mailbox. The .mbx suffix is assumed 
if not supplied. 

User_ids 

are access control names of the form 
Person_id.Project__id. tag. All entries with matching 
names are listed. If no User_ids are given, the entire 
ACL is listed. 

CONTROL ARGUMENTS 

-brief 
-bf 

suppresses the message "User name not on ACL" . 
-chase 

chases links matching a starname. The default is to 
chase a link only when specified by a non-starred 
pathname . 

-no__chase 

does not chase links when using the star convention. 
This is the default. 



Status permission is required on the parent directory. 
The active function has the following syntax: 
[mbla path {User^ids}] 
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I It returns the modes and access names of matching entries 
I separated by spaces (e.g., "adrosw A.B.* ao CD. a"). The -brief 
I control argument is assumed. 
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mbx_set_acl (mbsa) 

The mbx_set^acl command manipulates the access control lists 
of mailboxes. 

SYNTAX AS A COMMAND 

mbx_set_acl path model User_idl ... modeN {User_idN} {-ctl_args} 



ARGUMENTS 



path 

is the pathname of a mailbox. The .mbx suffix is assumed 
if not supplied. The star convention is allowed. 

modeN_ 

is an extended access mode, consisting of any or all of 
the letters "adrosw" or "null", "n", or "" for null 
access. 

User_idN 

are access control names of the form 

Person_id.Project_id. tag. All ACL entries with matching 
names are assigned modeN. If no match is found and all 
three components are given, an entry for User__idN is 
added to the ACL. If the last User_id is omitted, the 
user's Person_id and Project_id are assumed. 

CONTROL ARGUMENTS 



-brief 
-bf 

suppresses the message "No match for User__id" on ACL of 
<path>, where User_id omits components. 

-chase 

chases links matching a starname. Links are always 
chased when path is not a starname. 

-no_chase 

does not chase links when using the star convention. 
This is the default. 

-no_sysdaemon 
-nsd 

suppresses the addition of an "aow *.SysDaemon.*" term 
when using -replace. 
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mbx set_acl (mbsa) mbx set_acl (mbsa) 



I -replace 

I -rp 

1 deletes all ACL terms (with the exception of the default 

j * . SysDaemon . * term unless -no__sysdaemon is specified) 

I before adding the terms specified on the command line, 

j The default is to add to and modify the existing ACL. 

I -sysdaemon 

j -sd 

I with -replace, adds an "aow *. SysDaemon . *" ACL term 

{ before adding the terms specified on the command line. 



NOTES 



The user must have modify permission on the containing 
directory. 

I See the beginning of this appendix for an explanation of 

I User_id matching strategy. 
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APPENDIX C 



GLOSSARY 



The following list of terms is a supplement to the glossary 
provided in the New Users' Intro - Part I. Most of the terms 
appear for the first time here, but several are repeated. 



ADDRESS 

a form of name that directs mail system commands to 
mailboxes. The name is usually an entryname (Ching.mbx), 
a full pathname (>udd>ProjCat>Ching.mbx) , or a User__id 
(Ching.ProjCat ) . 



HEADER 

the group of lines preceding the text of a message, and 

containing information about the creation and destination 
of the message. Standard information included in the 

header is the User_id of the person who wrote the 

message, the date and time it was sent, the subject of 
the message, and who it was sent to. 



HEADER FIELD 

one specific kind of information contained in the header, 
such as the message subject (the Subject field) or the 
lists of recipients (the To and cc fields). Information 
for standard header fields is usually supplied 
automatically, but most header fields can be controlled 
with send_mail requests. 
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LOGBOX 



a mailbox in the home directory to which only the owner 
has access. It is created with the log request or the 
send__mail -log control argument, and has the pathname 
>udd>Pro ject_id>Person_id>Person_id. sv.mbx. The logbox 
is intended as a general mail storage container; see also 
savebox. 



MAILBOX 

a container for mail system messages, controlled by a set 
of extended access modes. Typically, each person has a 
mailbox named Person__id.mbx under the home directory, to 
which senders have limited access (access to read and 
delete the messages they send). Users may also create 
other mailboxes, called logboxes and saveboxes. 



MESSAGE 

in this manual, a "message" refers to a mail system 
message created by a user with the send_mail command. 
Other types of message are referred to by more specific 
names, such as interactive messages and error messages. 



MESSAGE SPECIFIER 

a combination of message numbers, keywords, character 
strings, and logical and arithmetic operators that are 
used with various read_mail requests to specify which 
messages are to be manipulated. 



REQUEST LINE 

one complete instruction, within the request loop, to 
send^mail or read_mail. It includes the request name, 
any arguments to the request {such as message specifiers 
and request control arguments), and a newline. A request 
line is parallel to a Multics command line, except that a 
request line is issued at request level. 



REQUEST LOOP 

a repeating cycle within read_mail and send_mail that 
prompts you for a request (e.g., read_mail:), reads the 
request you type, performs the specified operation, and 
finishes with a prompt to you for another request. The 
request loop is parallel to Multics command level, except 
that at command level no prompt is given. 
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SAVEBOX 



a mailbox created by the save request or the send_mail 
-save control argument, in any directory to which the 
owner has access. By default, users have access only to 
their own saveboxes. Users can create as many saveboxes 
as desired, to store mail by topic. 
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INDEX 



MISCELLANEOUS 

! (exclamation point) 4-10 

# character 3-2 

* (asterisk) 4-4 

. request 

read_mail 7-6, A-18 
send_mail 7-6, A-57 

. . escape request 7-5 

re-entering mail system 7-6 
read_mail A-18 
send_mail A- 58 

? request 

read_mail 4-12, A-18 
send_mail A-57 

@ character 3-2 
\f 



send mail 3-5 



\q 



read mail 4-7 
send mail 3-3 



abbrev 

active request 

read_mail A-19, A-58 
request 

profile 7-1 

read_mail 7-1, A-19 

send__mail 7-1, A-58 

accept_messages (am) command 
1-2, 1-6 

access 1-2 

to mail segments 6-5 

to mailboxes B-1 

to sent messages 6-5 

acknowledgement 3-7, 3-14 
Acknowledge-To field 3-7 

active functions 7-5, 7-7 

active requests 7-7 

address 3-1, 5-3, 5-4, A-52 
-comment 5-7 

-user and -^mbx 6-5 
deletion 5-5 

all 

active request 

read_mail A- 20 
keyword 4-4, 4-5 
request 

read mail A-19 
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answer request 
read^mail A- 20 
send^mail A- 58 

append request 

read_mail 6-6, A-22 
send__mail 6-6 

apply request 
read_mail A- 2 3 
send_mail 7-9, A-60 

asterisk (*) 4-4 



C 



cc 

field 5-5 

and your User__id 6-2, 6-4 
request 

send__inail 5-4, A-62 

command level 1-5 

and request level 1-5 
within mail system 7-5, 7-8 

comments (to addresses) 5-8 

control arguments 1-5, 7-3 
addresses 

-mbx 6-5 
and requests 1-5 
for addresses 

-comment 5-7 

-user 6-5 
pr int_mail 

-list 2-3 

complete list A-2 
read__mail 4-15 

-list 4-16 

-log 6-2 

-no__header 4-16 

-request 7-4 
send__mail 3-12 

-acknowledge 3-14 

-input__file 3-13 

-log 6-2 

-request_loop 3-13 
-save 6-3 
start_up.ec 7-4 



copy request 

read__mail A-24 
send_mail A-62 

current 

active request 

read_mail A- 2 5 
keyword 4-4 
message 4-5 
request 

read mail A-25 



D 



Date field 1-3 

delete request 

read_mail 4-3, 4-8, A-25 

deletion 

addresses 5-5 
header fields 5-5 
line 3-2 
message 4-8 
word 3-2 

do 

active request 

read_mail A- 2 7 

send_mail A-64 
request 

read_mail A-25 

send_mail A-62 

dprint command 6-5 



E 



editor 3-4 

other editors 7-9 
qedx 3-4 

Emacs 7-9 

enter_output_request command 
7-8 

erase (Q) character 3-2 
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examining mail 
logbox 6-2 

other mailboxes 6-5, 7-6 
saveboxes 6-5 

exclamation point (!) 4-10 

execute 

active request 

read_mail 7-7, 7-8, A-29 

send^mail 7-7, 7-8, A-65 

request 

read_mail 7-8, A-28 

send__mail 7-8, A-65 

exec_com 1-6 
active request 

read_mail A-28 

send_mail A-65 
and apply request 7-9 
request 

read_mail 7-9, A-27 

send_mail 7-9, A-64 
start_up 7-4 



H 



header 1-3, 4-7, 5-1, A-53 

comments 5-8 

fields 1-3 

Acknowledge-To 3-7 
cc 5-5, 6-2, 6-4 
complete list A-53 
Bate 1-3 
From 1-3, 5-7 
In-Reply-To 4-8 
Redistr ibuted-By 4-8 
Redistributed-Date 4-8 
Redistr ibuted-To 4-8 
Sender 5-7 

Subject 1-3, 5-6, 7-7 
To 1-3, 5-2 
modifications 5-5 

help request 

read_mail 4-14, A-30 
send mail 3-11, A-66 



extended access 1-2, B-1 



F 



fields 

see header fields, 5-2 

fill request 

send_mail 3-14, A-66 

first 

active request 

read_mail A-29 
keyword 4-4 
request 

read_mail A-29 

forward request 

read_mail 4-8, A-29 

from 

field 1-3, 5-7 
request 

send mail 5-7, A-66 



if 

active request 

read_mail A- 3 3 

send__mail A- 6 9 
request 

read_mail A- 3 2 

send_mail A- 68 

In-Reply-To field 4-8 

interactive message 1-2, 1-6 

in_reply_to request 
send mail A-69 



K 



keywords 4-4 
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M 



last 

active request 

read___mail A- 3 3 
keyword 4-4 
request 

read__mail A- 3 3 

link command 1-2 

linking mailboxes 1-2 

list 

active request 

read_mail A- 3 6 
request 

read__mail 4-2, 4-3, 4-8, 
A-34 
-idl 4-10 



mail 

commands 

print_mail 2-1, A-2 

read__mail 4-1, A-6 

recursion 7-6 

send_mail 3-1, 5-1, A-47 
mail segment 6-5 
suffix (.mail) 6-6 

mailbox 1-2 
active request 

read_mail 7-7, 7-8, A-37 
commands 1-2, B-1 
linking mailboxes 1-2 
logbox 6-1 
request 

read__mail A-37 
saveboxes 6-3 



list_help request 
read_mail A-36 
send__mail A-69 
read_mail 4-15 
send mail 3-12 



mbcr 

see mbx_create command 
mbda 

see mbx delete acl command 



list__or iginal 
active request 

send__mail A- 71 
request 

send mail A-70 



mbla 

see mbx_list_acl command 
mbsa 

see mbx set acl command 



list_requests request 
read_mail A-36 
send_mail A-71 
read_mail 4-13 
send mail 3-10 



log request 
read_mail 
send mail 



6-2, A-37 
6-2, A-72 



logbox 6-1 

examining mail 6-2 
storing mail 6-1 

log__or iginal 
request 

send mail A-72 



mbx_create (mbcr) command B-3 

mbx_delete__acl (mbda) command 
B-4 

mbx__list_acl (mbla) command 
B-5 

mbx_set__acl (mbsa) command 
B-7 

mbx_spec ification 
print_mail A-2 

message 1^3 
commands 

accept_messages 1-2, 1-6 
pr int_messages 1-2 
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message (cont) 
commands 

send_message 1-6 
interactive 1-2, 1-6 
numbers 4-2, 4-8 
specifiers 4-4 

ranges 4-5 

message specifiers A-10 

message_id request 
send mail A-72 



N 



next 

active request 

read_mail A- 3 7 
keyword 4-4 
request 

read mail A-37 



P 



preface request 6-7 
read_mail A-37 
send_mail A- 7 3 

previous 

active request 

read mail A-38 
keyword 4-4 
request 

read__mail A-38 

print request 

read_mail 4-2, 4-4, A-38 

-idl 4-11 
send_mail 3-3, A-73 

pr int__header request 
read__mail 4-7 
send_mail 3-4, 5-2, A-73 

print_mail (prm) command 1-1, 
2-1, A-2 
control arguments 
-list 2-3 
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print_mail (prm) command 
(cont) 
control arguments 

complete list A-2 
responses 2-2, A-4 

print_messages (pm) command 
1-2 

print__original request 
send_mail A-73 

print_original_header request 
send_mail A- 7 4 

prm 

see print_mail command 



Q 



q request (editor) 3-5 

qedx 

editor 3-5 
request 

send_mail 3-5, A-74 

quit request 

read_mail 4-3, 4-11, A-39 
send~mail 3-9, A-75 



R 



ranges 4-5 
rdm 

see read_mail command 

re-entering mail system 7-6 

ready request 
read_mail A-40 
send_mail A- 7 6 

ready_off request 
read_mail A-40 
send mail A-76 
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ready^on request 
read_mail A-40 
send_mail A- 7 6 

read__mail (rdm) command 1-1, 
4-1, A-6 
control arguments 4-15 

-abbrev 7-1 

-list 4-16 

-no^header 4-16 

-request 7-4 

complete list A-7 
recursion 7-6 
requests 

see requests 

recursion 7-6 

Redistr ibuted-By field 4-8 

Redistributed-Date field 4-8 

Redistr ibuted-To field 4-8 

remove request 

send_mail 5-5, A-7 6 

reply request 

read_mail 4-7, A-40 

reply_to request 
send__mail A- 7 7 

request level 

active requests 7-7 

request loop 1-4 

-request_loop control 

argument (sdm) 3-13 
send_mail 3-2, 4-7 

requests 1-4 

active requests 7-7 
read_mail 

abbrev A-19, A-58 
all A-20 
current A-25 
do A-27 

execute 7-7, A-29 
exec__com A-28 
first A-29 
if A-33 



requests (cont) 
active requests 
read__mail 

last A-33 

list A-36 

mailbox 7-8, A-37 

next A-37 

previous A-38 

subsystem_name A-45 

subsystem^version A-45 
send_mail 

do A-64 

execute 7-7, A-65 
exec_com A-65 
if A-69 

list__or iginal A-71 
subject 7-7, A-78 
subsystem_name A-78 
subsystem_version A-78 
print_mail responses 2-2, 

A-4 
read__mail 

. request 7-6, A-18 

. . escape 7-5 , A-18 

? 4-12, A-18 

abbrev A-19 

all A-19 

answer A-20 

append 6-6, A-22 

apply A-23 

copy A-24 

current A-25 

delete 4-3, 4-8, A-25 

do A-25 

execute 7-8, A-28 
exec_com A-27 
first A-29 
forward 4-8, A-29 
help 4-14, A-30 
if A-32 
last A-33 

list 4-2, 4-3, 4-8, A-34 

-idl 4-10 
list_help A-36 
list__requests A-36 
log 6-2, A-37 
mailbox A-37 
next A-37 
preface 6-7, A-37 
previous A-38 
Drint 4-2, 4-4, A-38 

-idl 4-11 
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requests (cont) 
read_mail 

quit 4=3, 4-11, A~3S 
ready A-40 
ready_off A-40 
ready_on A-40 
reply 4-7, A-40 
retrieve 4-10, A-44 
save A-45 

subsystem^name A-45 

subsystem^version A-45 

write 6-6, A-45 
request line 1-5 
request loop 1-4, 3-2, 4-7 
send_mail 

. request 7-6, A-57 
escape 7-5, A-58 

? 3-10, A-57 

abbrev A-58 

answer A-58 

append 6-6 

append path A-60 

apply 7-9, A-60 

cc 5-4, A-62 

copy A-62 

do A-62 

execute 7-8, A-65 
exec_com A-64 
fill A-66 
from 5-7, A-66 
help 3-11, A-66 
if A-68 

in_reply_to A-69 
list^help A-69 
list_or iginal A-70 
list_requests A-71 
log 6-2, A-72 
log_original A-72 
message_id A-72 
preface 6-7 
preface path A-73 
print 3-3, A-73 
print__header 3-4, 5-2, 
A-73 

print__or iginal A-73 
print_or iginal_header 

A-74 
qedx 3-5, A-74 
quit 3-9, A-75 
ready A-76 
ready_off A-76 
ready_on A-76 



requests (cont) 
send_mail 

remove 5-5, A-76 
reply^to A-77 
save 6-3 
save path A-77 
save__or iginal A-77 
send 3-7, 5-1, 5-3, 5-4, 
A-77 

-log and -save 6-4 
subject 5-6, A-78 
subsystem__name A-78 
subsystem__version A-78 
to 5-1, A-78 
write 6-6, A-79 
write_or iginal A-79 

retrieve request 

read mail 4-10, A-44 



save request 

read__mail A-45 
send_mail 6-3, A-77 

savebox 6-3 
examining 6-5 
storing mail 6-3 

save__or iginal request 
send_mail A-77 

sdm 

see send__mail command 
segments 6-5 

selection control arguments 
A-13 

send request 

logging and saving 6-4 
send__mail 3-7, 5-1, 5-3^, 
5-4, A-77 

Sender field 5-7 

send_mail (sdm) command 1-1, 
3-1, 5-1, A-47 
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send_mail (sdm) command (cont) 
control arguments 3-12 
-abbrev 7-1 
-acknowledge 3-14 
-comment 5-7 
-input__file 3-13 
-log 6-2 

-request_loop 3-13 

-save 6-3 

complete list A-48 
recursion 7-6 
requests 

see requests 

send_message (sm) command 1-6 

start_up.ec 1-6, 7-4 

storing mail 6-1 
logbox 6-1 
saveboxes 6-3 

subject 

active request 

send_mail 7-7, A-78 
field 1-3, 5-6 
of a message 3-1 
request 

send mail 5-6, A-78 



text editor 
emacs 7-9 
others 7-9 
qedx 3-4 



to 



field 1-3 
request 

send_mail 
send mail 



5-1, A-78 
5-2 



W 



write request 

read__mail 6-6, A-45 
send_mail 6-6, A-79 

wr i te_or iginal 
request 

send mail A-79 



subsystem_name 
active request 
read_mail A-45 
send_mail A-78 
request 

read_mail A-45 
send_mail A-78 

subsystem_version 
active request 
read__mail A-45 
send__mail A-78 
request 

read__mail A-45 
send mail A-78 



suf f ix 

.mail 6-6 
.sv.mbx 6-1, 6-3 
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